An Overview of 5G Slicing Operational Business Models for Internet of Vehicles, Maritime IoT Applications and Connectivity Solutions

Identification of ecosystems and Business Models (BM) is an important starting point for new complex system development. The definition of actor (or stakeholder) roles and their interactions (at both business and technical levels), together with target scenarios and use cases, provide essential input information for further system requirement collection and architecture specification. The powerful and flexible Fifth Generation (5G) network slicing technology, which is capable of creating virtually isolated and logically parallel networks, enables a large range of complex services and vertical applications. Although various terminologies and models have been proposed in recent years for BMs in the 5G domain by many studies, projects, standards, and technical specifications from dedicated organizations, they are not always consistent with each other. This study presents an overview and comparison of different BMs for 5G sliced systems, followed by an example on BM definition for a 5G system in a novel ongoing European research project. While a general ecosystem and business model could involve a large range of organizations (including, e.g., regulation and standardization bodies), the scope of this article will be limited to primarily 5G operational BMs, with a focus on those actors or stakeholders who are active and interacting during real-life system operation. Within the project, we perform a selection among some tailored BM configurations, adapted for dedicated slices with different service requirements, aiming to serve Vehicle to Everything (V2X) and Internet of Vehicles (IoV) applications as well as Internet of Things (IoT) for maritime vertical applications. The final part of this article presents our proposed IoT connectivity solutions for various maritime scenarios with and without involving satellite links. Furthermore, we shed light on future challenges and directions for network slicing in beyond 5G systems.

focused on objectives with different interests, representing the perspective from a specific working group or stakeholder. Currently, the terminologies ecosystem and BM expose a multi-semantic characteristic in different studies [5].
In a general sense, a business ecosystem is a network of organizations/stakeholders such as suppliers, technology and service providers, distributors, customers, competitors, government agencies, regulators, etc., involved in the development and delivery of a specific product or service through both competition and cooperation [6]. Traditionally, in the telecommunication world, ecosystem has been a frequently used terminology in mobile communication industries, including terminal equipment and network providers, communication service providers and Over-The-Top (OTT) providers. However, in the Fifth Generation (5G) domain, the semantic of ecosystem has been expanded to include also other entities, e.g., the industries which are served [7]. In particular, Communication Service Providers (CSPs), Network Providers (NPs), and different enterprises collaborate to form an ecosystem. The involved stakeholders/actors/entities interact with each other in order to achieve together the system goals (in the rest of this article, the terminologies stakeholders and actors are interchangeably used, whereas entity is a more general and abstract terminology used on some models). In many studies, ecosystem and BM are considered as being equivalent. In other studies, the terminology ecosystem business model is also used [8].
In this study, a BM is regarded as a part of a general ecosystem, i.e., the BM is more limited in terms of number of environment entities considered in the system representation. On the other hand, a system can be treated either from a technical point of view, or from a commercial-business point of view. The initial system development phase and its commercial-business aspects can also be structured in a commercial-oriented BM, whereas the major system functionalities can be described in a so-called technical BM. Obviously, the two models are interdependent.
This article focuses mainly on technical BMs, whose definition aims to provide input information in the system functional architecture specification phase. In the framework of 5G technologies, the capabilities provided by network slicing to create virtually parallel and dedicated networks offer a powerful and unique opportunity for supporting a large range of complex services and applications. Consequently, appropriate BMs should be identified and selected among multiple solutions. This article provides a critical overview on different 5G slicing BMs, and ends up with a selection example of a few tailored configurations adapted for dedicated slices, to serve Internet of Things (IoT), in both consumer IoT and industrial IoT branches [9], Vehicle to Everything (V2X), Internet of Vehicles (IoV), and systems for maritime applications [10]. While general ecosystems and BMs could involve a large range of organizations (including e.g., the regulation and standardization bodies), this study focuses on so-called Operational BMs (OBMs), which contain only those actors that are active and interact with each other during real-life system operation. Existing BMs proposed in the standards and literature for 5G and its slicing developments will be briefly presented and compared with respect to several criteria such as flexibility, complexity, roles of the actors, scalability, multi-domain, multi-operator, and multi-tenant capabilities. Then, mainstream and potentially selectable models will be considered and compared, among those proposed by the 3rd Generation Partnership Project (3GPP), 5G Infrastructure Public Private Partnership (5G-PPP), European Telecommunications Standards Institute (ETSI), and various 5G-oriented projects. Afterwards, the BMs (roles, actors, and interactions) will be defined for a novel 5G-based complex system developed in the framework of an ongoing European Economic Area research project ''A Massive MIMO Enabled IoT Platform with Networking Slicing for Beyond 5G IoV/V2X and Maritime Services (SOLID-B5G)'' [11]. The main goal of the SOLID-B5G project is to develop breakthrough beyond state-of-the-art solutions in orchestration management and control of resources, in the context of network slicing and edge computing based on massive IoT (mIoT) enabled radio access network (RAN) and core network (CN) for beyond 5G IoV/V2X and maritime applications. The proposed solutions by the SOLID-B5G project for IoT connections for maritime applications are also presented. Finally, we shed light on challenges and future research directions within this topic for beyond 5G network sliced systems.
The remainder of this article is structured as follows. Section II discusses general 5G ecosystems and business models with a focus on 5G sliced systems. A comparison will be made among several models. Section III identifies a few important aspects related to multi-tenant, multi-domain, and multi-operator systems. Section IV deals with specific BMs for V2X, IoV, and IoT applied to maritime communication systems. Considering the potential BMs discussed in Sections II-IV, Section V defines BMs appropriate for the scenarios and use cases envisaged in the SOLID-B5G project and presents six proposed solutions for IoT connectivity. Challenges and future directions are presented in Section VI. Finally, Section VII concludes the article.

II. 5G ECOSYSTEMS AND BUSINESS MODELS
This section presents a summary of some major ecosystems and business models proposed for 5G. A comparison will be performed considering their main characteristics. The focus of our study will be on 5G sliced systems.

A. GENERAL 5G ECOSYSTEMS
The purpose of this subsection is to illustrate the complexity and richness of a general ecosystem in the 5G era. Only a part of this ecosystem, i.e., BMs, will be further investigated in the rest of the article.
The mobile communication and 5G community ecosystem definitions [12], [13] capture the systemic nature of the 5G technologies and markets. In brief, industries adopt the terminology ecosystem in two slightly different ways: Communications Association (GSMA) and the International Telecommunication Union (ITU) is a refined terminology to broaden the market beyond mobile operators, including device manufacturers, equipment vendors, retail operators, software companies, and organizations in adjacent industry sectors.
• Ecosystem is a terminology adopted for more specific cases where a platform enables surrounding firms to innovate and create values in order to scale up the total market. Apple's App Store is often referred to as an exemplar of this concept.
Furthermore, two recognized ecosystem concepts originate from the business management and innovation domain, namely, (a) the value network [14] and (b) the platform ecosystem [15].
These concepts capture the complex interdependence of value creation. While the former is more detailed and usually focuses on a single industry such as telecommunications, utilities, or transportation, the latter pays particular attention to composite services enabled by one key market player and supported by several supplementary entities that may span across several industries. These concepts could be instantiated in the 5G context [15] by considering the 5G ecosystem as either a complex network or an interconnected system. The models are recognized as being complementary.
• Introvert view: 5G value network focuses on how 5G services are provisioned. Such models reveal platform internal complexity and hide the complexity of the interaction with customers and external partners.
• Extrovert view: 5G platform ecosystem focuses on how one 5G platform interacts with the external world. The model hides the platform internal complexity and explains in an explicit way the interactions with customers and external partners belonging to other industry domains.
A 5G-PPP vision on a general and complete ecosystem business model is presented in [16]. The model consists of several categories of stakeholders such as 5G industry and research, 5G complementary industry, verticals, policy makers, financing bodies, standards and open source organizations, 5G related organizations, and vertical associations. In the context of the SOLID-B5G project, the most important categories are those that include active actors in the OBM. Examples include 5G industry and research category, 5G complementary industry, and verticals.

1) 5G INDUSTRY AND RESEARCH CATEGORY
This category contains any general business or research activities, or commercial enterprises that apply 5G technologies or have activities related to 5G. It includes connectivity and higher layer service providers, technology providers and developers, Small and Medium Enterprises (SMEs) and research institutions.
As a generic category, connectivity and higher layer service providers perform daily operational activities with respect to network connectivity and/or service provisioning via wired/wireless networks. Such providers could be: • Network Operators (NOs) that provide access to a telecommunications network (e.g., a mobile phone network) or to the Internet.
• Small cell operators that enable Mobile Network Operators (MNOs) to deploy sites in strategic locations offering smaller coverage with higher capacities (using licensed or unlicensed spectrum).
• Hotspot providers that offer Internet access (typically via Wireless Fidelity (WiFi)).
• Service Providers (SPs) that provide Internet services or other value-added services, e.g., cloud computing, storage, e-learning, etc. SP is a more general terminology used to refer to third party or outsourced suppliers including Telecommunications Service Providers (TSPs), Application Service Providers (ASPs), Storage Service Providers (SSPs), Internet Service Providers (ISPs), and cloud/edge providers.
• OTT Providers that offer media services directly to end users via the Internet; usually they are not the owners of a network infrastructure. In particular: -ASPs provide computer-based solutions/services to customers over a network, such as access to a software solution/application (e.g., customer relationship management) using standard protocols (e.g., the Hypertext Transfer Protocol (HTTP)). -Technology providers and developers develop and provide technology solution(s) which can be used by 5G-PPP projects, SMEs, start-ups, etc.
• Chip and component makers buy raw materials from their suppliers, assemble these into components and pass their products to other manufacturers.
• Developers (including both individuals and institutions) build and create software applications. These engineers write, debug, and execute the source codes of a software application.
• Device or Software, which is an object or machine, a piece of mechanical or electronic equipment, has been constructed to fulfill a particular purpose. A device typically includes both hardware and software.
• SMEs utilize services and infrastructures provided by a project, making their products available to developers or end-users. An SME can be also a developer who can perform its own test using the services offered by 5G-PPP projects and infrastructures in order to develop its products, solutions, or systems. SMEs include startups, spin-offs, niche players, etc.
2) 5G COMPLEMENTARY INDUSTRY 5G Complementary Industry represents a rich category [16] including Information Technology (IT) system and network integrators, IT consulting, Digital Services Providers  DSPs are enterprises that offer digital services to end-users. Such an enterprise may have a role partially overlapping with SPs and ASPs of the 5G Industry and Research category.
IT Management of Network and Software: During system operation, network management tools automatically monitor active nodes, traffic, perform revision management, and assure security. Fault detection and isolation as well as resolution should be performed to optimize network efficiency and avoid any downtime. A service supplier should install and configure a network management system which manages user moves, adds, or changes on the network, as well as network software and hardware upgrades.
M2M component providers are enterprises offering solutions that enable networked devices to exchange information and perform actions without any manual intervention or assistance of human beings.

3) VERTICALS
These are enterprises that take the advantages of 5G infrastructures to create or offer high level services to their users, or they could be themselves consumers of certain services. Such enterprises can play active roles in a particular OBM.
Examples of verticals include Automotive (car technology providers, manufacturers, automotive services); Broadcasting and Media (studios, broadcasters, content providers, satellite and cable providers, media service providers); Consumers (organizations or individuals); Energy (power companies, utilities, large users, smart grid operators); Public safety (police, rescue and fire departments, emergency medical professionals, army, hospitals, ambulance, drone industry); Agriculture and farming; Healthcare (hospitals, healthcare companies, insurance companies, health providers); Smart cities (transport and traffic management, parking, street lighting, tourism, governance, smart economy, environment, mobility, industry); Transport and logistics (rail, maritime, aviation, road); Factories of the future.
The other stakeholders which are included by a 5G-PPP report [16] in the ecosystem general model, like policy makers and financing bodies, standards and open source organizations, 5G related organizations, and vertical associations will be not detailed in this article. This is because these actors act directly only in the development phase of a system but not in the operation phase.

B. 5G GENERAL BUSINESS MODELS
This subsection presents an overview on 5G OBMs as they are defined by major organizations involved in this domain, i.e., 5G-PPP and 3GPP. • Service Provider. It designs, builds, and operates high level services, on top of aggregated network services. An SP plays a generic role, comprising three possible sub-roles, depending on the service offered to an SC: -A communication service provider offers traditional telecommunication services; -A DSP offers digital services (e.g., enhanced mobile broadband and IoT to various verticals); -A Network Slice as a Service (NSaaS) provider offers a network slice and its services.
• Network Operator. An NO orchestrates resources that are potentially offered by multiple virtualized infrastructure providers. It utilizes aggregated virtualized infrastructure services to design, build, and operate network services to be offered to SPs.
• Virtualization Infrastructure Service Provider (VISP). It builds and operates virtualization infrastructure(s) (i.e., networking and computing resources) and then offers virtualized infrastructure services. Sometimes, a VISP offers access to a variety of resources by aggregating multiple technology domains and making them accessible through a single Application Programming Interface (API).
• Data Center Service Provider (DCSP). It designs, builds, operates, and offers data center services. A DCSP differs from a VISP and it offers raw resources (i.e., host servers) in rather centralized locations and simple services for consumption of these raw resources. As shown in Figure 1, a top-down view of the layered hierarchy of this model includes SC, SP, NO, VISP, and DCSP. Note that, in practice, a single organization can play one or more roles from the above list. Furthermore, several 5G-PPP Phase I/II collaborative research projects have been performed (see examples in [18]). Some of them extended the list of role definitions, allowing various possible customer-provider relationships among verticals, operators, and other stakeholders.
Note further in Figure 1 that three auxiliary actors (i.e., Network Services Aggregator, Infrastructure Aggregator, and Data Center aggregator) may exist and they play essentially aggregation and orchestration roles. However, their functions could be embedded in the main actors if the design approach selects this option. The 5G-PPP BM does not elaborate the roles inside an Operation Support Provider (OSP) and hardware/software suppliers.

2) 3GPP BUSINESS MODEL
A 3GPP document, TR 28.801 [19], defines a business model including a set of stakeholders and their roles. As illustrated in Figure 2, the model is similar to that of the 5G-PPP with the stakeholders and their roles described below.
• A Communication Service Customer (CSC) uses communication services.
• A communication service provider designs, builds, and operates communication services.
• A network operator designs, builds, and operates its network-level services.
• A virtualized infrastructure service provider designs, builds, and operates its virtualization infrastructure(s). The VISPs may also offer their virtualized infrastructure services to other types of customers, maybe to CSPs directly, i.e., without going through a NO.
• A data center service provider designs, builds, and operates its data centers. As shown in Figure 2, the NO, VISP and DCSP could be the clients of the following providers, respectively: • Network Equipment Provider (NEP) which supplies network equipment. For the sake of simplicity, a Virtual Network Function (VNF) supplier is considered here as a type of NEP; • Network Function Virtualization Infrastructure (NFVI) supplier. It offers virtualization infrastructure to its customers; • Hardware supplier that supplies hardware. Moreover, an organization can play one or multiple roles defined above. Note that the list of roles above is not exhaustive. Furthermore, there exists mapping between the 3GPP model and the 5G-PPP counterpart. A CSC which is the upper layer (e.g., Industry 4.0) utilizes services provided by a CSP, thus playing the role of an end-user. A CSP organizes and structures its communication services on top of the NO it relies on. To perform this task, the CSP may request, for instance, a network slice template from the NO portfolio (e.g., the Industry 4.0 service may require massive Machine-Type Communications (mMTC) or enhanced Mobile Broadband (eMBB) slice instances). NOs have a direct connection with NEPs with their roles described above. To build network slice instances, they may deploy VNFs from one or more NEPs, which are finally executed in the underlying cloud infrastructure. The VISPs provide virtualized connectivity by using the hardware from one or more NFVI supplier (offering e.g., transport network functionality). The DCSP finally offers the bare metal resources (acquired from a hardware supplier) to run the service requested by CSCs.

C. 5G SLICING BUSINESS MODELS
The 5G BMs presented in the above two subsections have been generic, in the sense that they do not elaborate in an explicit way the roles that network slicing related entities play. In this subsection, we explore such aspects through two representative models.

1) A SLICING MODEL WITH THREE ROLES
A simplified model presented in [20] defines three main stakeholders with their roles, as summarized below.
• An Infrastructure Provider (InP) owns and manages a physical network as well as its constituent resources. Such resources (e.g., Wide Area Networks (WANs) and/or data centers) can be virtualized and then offered through an API to a single or to multiple tenants.
• A Tenant leases virtual resources from one or more InPs in form of a virtual network, where the tenant can realize, manage, and provide network slices which in turn realize network services for end-users. A network service is provided through a composition of VNFs, and it is defined in terms of individual VNFs and the mechanism used to connect them, i.e., VNF graphs. In this model, a tenant is equivalent to a Virtual Network Service Provider (VNSP).
• An End-User consumes (part of) the services supplied by a tenant, without the need for these services provided by other business actors.
Note that the above model is recursive. That is, one or several layers of tenants may exist, where a level-n tenant can offer virtual networks (i.e., slices) to a level-(n + 1) tenant. However, the tenant role in this model is very complex, given that it should create slices, maybe exploit them and possibly offer them to other tenants. Therefore, better refined models would be more valuable for real-world systems.

2) A SLICING MODEL WITH FOUR ROLES
In [18], a more refined model is defined including four main roles, as summarized below.
• An InP owns and manages the physical infrastructure (network/cloud/data center). It could lease its infrastructure (as it is) to a slice provider, or it can construct slices itself (the BM is flexible with this respect) and then lease the infrastructure in a network slicing fashion.
• A Network Slice Provider (NSLP) can be a typical telecommunication service provider (the owner or tenant of the infrastructures from which network slices are constructed). The NSLP can construct multi-tenant, multidomain slices on top of infrastructures offered by one or several InPs.
• A Slice Tenant (SLT) in this model is a generic user of a specific slice including network/cloud/data centers, which can host customized services. An SLT can request an NSLP to create a new slice instance dedicated to support certain SLT specific services. The SLT can lease virtual resources from one or more NSLPs in form of a virtual network, where the tenant can realize, manage, and then provide network services to its individual end users. A single tenant may define and run one or several slices in its domain.
• An End-User consumes (part of) the services supplied by a tenant, without the need for these services provided by other business actors.
Note that this model has a clearer distinction (with respect to the three role model) between the slice provider and tenant (generic user). The above BMs can be viewed from different perspectives.
• From a business point of view, a slice instance is a combination of all relevant network resources, functions, and assets required to fulfill a specific business case or service, including operation system support, business system support, and DevOps (which is a set of practices that combine software development (Dev) with IT operations (Ops)).
• From an infrastructure point of view, a slice instance requires the partitioning and assignment of a set of resources that can be used in an isolated, disjunctive or non-disjunctive manner with respect to other slices. Infrastructure resources include connectivity, computation, and storage resources.
• From a tenant point of view, a slice instance provides different capabilities, in terms of data transport features as well as their management and control capabilities.
Here it is important to design how much of the management and control capabilities the NSLP allows to the slice tenant.
• From a management plane point of view, network slices refer to the managed fully functional and dynamically created partitions of physical/virtual network resources, and service functions that can act as an independent VOLUME 9, 2021 instance of a connected network and/or as a network cloud.
• From a data plane viewpoint, network slices refer to dynamically created partitions of network forwarding devices with guarantees for isolation and security.

D. COMPARISON OF SLICING BUSINESS MODELS IN RESEARCH PROJECTS
Generally, the basic models outlined in the previous subsection constitute the reference models. However, distinctions exist among different approaches, depending on the main objectives of each particular project. For comparison purposes, this subsection presents a few relevant BMs adopted in several 5G research projects. Note however that this subsection does not intend to provide an exhaustive survey of all BMs proposed in different 5G projects.

1) 5G-NORMA
Similar to the basic models, the BM presented in the 5G-NORMA project contains three main stakeholders [21]: • An infrastructure provider owns and manages parts of or all of the network infrastructure. The InP offers an Infrastructure-as-a-Service (IaaS) to the Mobile Service Provider (MSP). The InP role may be further divided into antenna and radio equipment provider; transport network provider; and DCSP.
• An MSP provides mobile Internet connectivity to end-users either directly, based on a business-tocustomer relationship or via an intermediate tenant, i.e., a business-to-business or business-to-business-toanyone relationship. The MSP can construct dedicated logical mobile networks based on Network Slice Instances (NSLIs) realizing relevant network function chains to support instantiated services, e.g., inside eMBB or mMTC slices. In case of intermediate tenants, the MSP's offerings are NSaaS or Platform as a Service (PaaS). The MSP is responsible for design, building, and operation of its service offerings.
• A Tenant buys and leverages a network slice and the associated services provided by an MSP. A tenant can be, for instance, a Mobile Virtual Network Operator (MVNO), an enterprise (e.g., from a vertical industry), or another organization that requires telecommunication services for their internal business or for offering to their customers.
In the 5G-NORMA vision, the roles of MSP and InP can be vertically integrated into a single stakeholder entity namely Mobile Network Operator (MNO). In practice, there may also exist a so-called VISP which designs, builds, and operates its virtualization infrastructure(s) on top of InP services provided by one or more DCSPs. The VISP offers its infrastructure service to the MSP. Other roles are: the hardware supplier offering hardware (server, antenna, cable, etc) to the InPs, the NFVI supplier providing the corresponding NFV infrastructure to its customers, i.e., to the VISP and/or directly to the MSP, respectively. Lastly, the VNF supplier offers virtualized software components to the MSP.

2) 5G EXCHANGE (5GEx)
The 5GEx project proposes a more refined model and it makes distinction between two types of business roles [22]: • External customer role: A 5G customer in 5GEx vision could be an enterprise customer (a 5G enterprise customer), e.g., an SME or a large enterprise, a specific industry vertical or a DSP offering application services to their own end-users. Users' access could be obtained through basic best-effort Internet access services, Virtual Private Network (VPN), or even an evolved Internet access service. The 5G enterprise customer purchases the 5G enterprise service from a primary provider.
• Primary/customer-facing provider role: This role is needed to directly deal with external customers. It is implemented in some of the 5GEx actors. Those who implement this role should offer an interface to external parties for describing the available services and for negotiating as well as selling these services. The actor roles defined in the 5GEx project are: 5G-enabled NFV IaaS and can also provide services directly to a 5G enterprise customer. If present, a Cloud Service Provider (CdSP) also belongs to this category and offers IaaS.
• A (5G) Network Service Provider (NSP) offers network-level services (belonging to architecture layers L2/L3. The network service scope can be assigned through private addressing as well as according to public addressing such as the Internet address scheme. • A (5G) communication service provider offers 5G compatible communication services (e.g., voice, video, or more advanced services). More services belong to this category, such as unified communication and collaboration services, or live event real-time content delivery.
• An Online Applications service Provider (OAP, also known as Over-The-Top Service Provider (OTTSP)) offers online digital application services which do not belong to the category of communication services. For instance, large OTTSPs like Google or Netflix fall into this category. The 5G solutions that can offer value added connectivity services as well as communication services will allow a new range of OAPs to create novel businesses and values to their own customers.
• An Exchange Point service Provider (XPP) operates an exchange point solution. An XPP can play the role of an aggregator, supporting consumers and providers in developing an exchange point such that automation and interaction orchestration are possible.
• A 5G enterprise customer is a general user of system high level services. The 5GEx proposal enables solutions for 5G enabled and 5G compatible SP-to-SP wholesale service trading where the actor roles can meet and interact, either privately at their agreed private point of interaction or at exchange points (where multiple such 5GEx actors meet and can trade 5GEx services according to the 5GEx service specification).

3) 5G-TRANSFORMER (5G-T)
The 5G-T project [23] develops mobile transport networks with flexible and scalable Software Defined Network (SDN)/NFV based transport and communication infrastructures. It offers customized slices for vertical industries. It can also aggregate and federate transport networks and computing fabric from the edge up to the core and cloud, aiming to create and manage slices on top of a federated virtualized infrastructure.
The stakeholders for the 5G-T system are defined in a top-down approach [23], as summarized below.
• A Telecommunication Service Consumer (TSC) uses 5G-T services that are offered by a 5G-T SP. The model is flexible in a sense that a 5G-T SP can also be a TSC of another SP through federation. In the context of 5G-T, the main role considered as a consumer of services is the vertical industry.
• A telecommunication service provider provides 5G-T services. A TSP designs, builds, and operates its 5G-T services.
• A Mobile Transport and Computing Platform Operator (MTCPO) is in charge of orchestrating resources, potentially from multiple virtual infrastructure providers offered to the TSP. That is, it acts as an aggregator of resources. The virtual infrastructure features transport and computing resources, potentially including those DCSPs with which the MTCPO has an agreement. The MTCPO designs, builds, and operates the computing and network aggregated virtual infrastructure services and it has agreements with VISPs.
• A VISP provides virtualized infrastructure services based on the virtualization infrastructure(s) it designs, builds, and operates. A VISP can be further specialized depending on the kind of infrastructure it manages. While a VISP transport provider offers virtual transport infrastructures, a VISP computing provider supplies virtual computing infrastructures.
• A DCSP provides data center services based on the data centers it designs, builds, and operates. The difference between a DCSP and a VISP computing provider is that the former is closer to the raw resources (host servers) offering simple services of raw resource consumption. Additionally, these resources are located in a centralized location (data center). A VISP computing provider offers access to a variety of virtual infrastructure resources created by aggregating multiple technology domains and by making them accessible through a single API for all of them. For instance, it may offer not only centralized data center resources, but also distributed computing resources available throughout the network.

4) 5G-MONARCH
The 5G-MONARCH project [24] proposes an ecosystem model for 5G slicing. In this system, the role of a mobile network operator may change from a vertically integrated stakeholder which owns the spectrum, antennas, core network sites and equipment, to a layered stakeholder where each layer might be managed or implemented by a different party. A stakeholder is defined in [24] as an individual, entity, or organization that affects how the overall system operates. The 5G-MONARCH stakeholder roles are: • An End-User is the ultimate entity which uses the services provided by a tenant or an MSP.
• A Tenant purchases and utilizes a network slice and its associated services offered by an MSP. Tenant examples include MVNO, enterprise, or any entity that requires telecommunication services for its business operations.
• An MSP is the main entity which provides mobile Internet connectivity and telecommunication services to its end-users. To this end, an MSP constructs network slices and their function chains to compose services. Examples of slices can be eMBB or mMTC. The MSP set of tasks comprises design, building, offering, and operation of its services based on slicing.
• An InP owns and manages the network infrastructure (antennas, base stations, remote radio heads, data centers, etc.) and offers it to the MSP, in the form of IaaS.
In practice, a larger organizational entity, e.g., an MNO, could operate and own a mobile network, combining the roles of MSP and InP.
The 5G-MONARCH model further refines the roles of other entities which may exist, as distinct actors: • A VISP may exist, as an intermediate actor between an InP and an MSP. It designs, builds, and operates a virtualization infrastructure on top of the InP services, and offers its infrastructure services to the MSP.
• At a lower logical level, an NFVI supplier may exist, providing an NFV infrastructure to its customers, i.e., to the VISP and/or directly to the MSP.
The BMs adopted in different projects can be generally mapped (but not always in a one-to-one relationship) onto the 3GPP model, as shown in Table 1. Given the complexity of an overall multi-stakeholder system, its heterogeneity is recognized and is still present among different BM definitions. Diverse terminologies have been adopted by different stakeholders performing the same tasks. On the other side, it is inherent given that independent developments have been conducted in the same period of time. A lesson learnt from the above overview is that, for a new system to be defined and designed, one should consider as a basis the reference BMs (for example from 3GPP, 5G-PPP, etc.) but then carefully customize them to the target objectives and system scale.

III. E2E SLICING IN MULTI-TENANT, MULTI-DOMAIN, AND MULTI-OPERATOR ENVIRONMENTS
The BM models presented above do not address in-depth aspects related to multi-domain, multi-operator, and End-to-End (E2E) slices. Nor do they elaborate on what changes may emerge with respect to stakeholders and roles when such an environment is considered. An exception is the 5GEx project which considered some multi-domain problems. Based on this observation, we discuss in this section some aspects of E2E network slicing in multi-tenant, multi-domain, multioperator environments.

A. STAKEHOLDERS AND ROLES FOR MULTI-TENANT, MULTI-DOMAIN SLICING
Creating multi-tenant, multi-domain, multi-operator E2E slices has impact on BMs in such environments, given the need of cooperation between independent (organizational and technical) entities while preserving their independence attributes at a reasonable level.

1) MULTI-TENANT SLICING
A 5G sliced system should be multi-tenant capable. Accordingly, several requirements need to be satisfied. A multitenant 5G system is expected to 1) perform on-demand (per-tenant) dedicated slice creation, allocation, modification, isolation, and deletion of slices for different tenants; 2) to allocate slices to different tenants concurrently on top of a common shared infrastructure; 3) to provide suitable APIs, allowing tenants to perform specific slice monitoring and management; 4) to provide elastic adaptation within minimum and maximum limits of the slice capacity for a given tenant; and 5) to possibly support slice prioritization among various tenants.
For the time being, no single definition of a tenant has reached a general consensus. Consequently, the definition of stakeholders and roles in a BM may be affected by this ambiguity. A short comparison is summarized below.
In [20], a tenant actor is defined as an entity who leases virtual resources from one or more InPs in form of a virtual network, where the tenant can construct, manage, and provide network slices which in turn realize network services for end-users. Therefore, the tenant is also the builder of network slices and could be regarded as a VNSP. Correspondingly, the business model defined therein is flexible and recursive, with a layered hierarchy supporting co-existing tenants. A tenant at one layer can play the role of an InP for the upper layer. Furthermore, a tenant can provide network services not only to an end-user but also to another tenant.
On the other hand, the work in [18] defines a tenant actor as a slice tenant who is a generic user of a specific slice, including network/cloud/data centers, which can host customized services. Therein, an NSLP is the actual builder of slices. An SLT can request from an NSLP to create a new slice instance dedicated to support certain SLT specific services. The SLT can lease virtual resources from one or more NSLPs in form of a virtual network, where the tenant can realize, manage, and then provide network services to its individual end-users. A single tenant may define, request, and run one or several slices in its domain.
Moreover, a tenant actor in [25] is defined as a business entity that rents and leverages an NSL provided by a network operator. The NO is the actual builder of slices. The tenant actors can be MVNOs, other enterprises (e.g., vertical industries), or other organizations that require telecommunication services. The physical resources and computing entities, which are virtualized into isolated and independent slices, are shared among the MVNOs.

2) MULTI-TENANT AND MULTI-DOMAIN SLICING
A 3GPP document, TR 28.804 [26], has proposed a BM and architecture for multi-tenant and multi-domain 5G slicing systems. In the 3GPP model, three actors or stakeholders exist, i.e., InP(s) (one or several, the latter in a multi-domain environment); tenant(s) (one or several, the latter for multitenants); and end-users (many).
In that model, each tenant can construct several dedicated slices on top of the infrastructure provided by an InP or InPs. Since the model applies also to multi-domain, several InPs may cooperate and actually offer to a tenant not only bare metal hardware resources but also a full NFVI which is managed in the NFV style. What is important from the viewpoint of actors and roles is that each tenant has management and control capabilities upon its slices (based on NFV and SDN technologies). These network slices are operated in parallel upon a shared underlying NFVI. The resources of the shared underlying NFVI are owned and managed by different InP actors, each defining a different infrastructure domain. The NFVI resources owned and managed by the InPs are delivered to the tenants logically placed on top of them. Each tenant makes use of the NFVI resources supplied by the underlying InP to meet the service requirements of the slices in the tenant domain. The resources in this model are represented in the NFV IaaS type.

B. STAKEHOLDERS AND ROLES FOR MULTI-DOMAIN, MULTI-OPERATOR, AND E2E SLICING
Multi-domain E2E slicing architectures and especially multi-domain orchestration are important topics and they have been addressed by the standardization and research communities as well as 3GPP, 5G Americas, and many 5G-PPP projects. To provide E2E services, slices should be created across multiple technological or administrative domains. However, not all slices are composed of domains with full functionality, due to different slice specific requirements or limited ownership capabilities. An E2E slice template should be aware of capabilities of each administrative domain.
A challenging task to enable this multi-domain capability is how to make a trade-off between the business and technical independence for each BM actor and the need for coordinating the management and orchestration of the assembly, in order to offer end-users an E2E slice crossing diverse domains.
The BM needs to contain multiple stakeholders and will have impact on the overall system architecture. More specifically, 1) Interfaces should be defined among different owners/operators; 2) A business interface, which allows slice operators (tenants) to perform slice management especially to create E2E slices over multiple administrative domains, is needed; 3) A slice operator should have high-level management capabilities that include policy based management, configuration, security operations, accounting, and performance monitoring; and 4) A slice orchestrator should exit, to perform automatic fault detection and performance management.
Furthermore, an orchestrator operator, a slice operator (or even end-users in some cases) should be able to create/request a slice. In the latter case (which requires slice on-demand), the slice characteristics should be advertised, and its roll-out time is a critical performance indicator. In addition, there must be an administrative interface between a slice operator and a slice provider.
To create an E2E slice, it is necessary to go across multiple technological or/and administrative domains. Creating slices in such cases can be performed, generally, by two means: • Direct creation of the E2E capability on a slice.
In this approach, the first step is to integrate all domain resources via multi-domain resource orchestration. A special BM actor, which plays the role of orchestration, is needed. Since a multi-role actor is expected, this role could be played by one of the regular actors (e.g., a VMNO). Later on, the orchestrator that initiated the process deploys a network slice similar to a single domain case.
In the single domain case, a single slice template is sufficient. When different administrative domains coexist, however, the approach of direct creation has limited applicability especially when diverse technologies are adopted in different domains. This is because to exchange information among orchestrators about each domain's specificity (heterogeneous hardware nodes or whole subsystems) could be difficult or troublesome.
• Creation of per-domain sub-slices and stitching them together. This solution follows a hierarchical approach where per-domain orchestrators are loosely coupled with a special entity known as Business Service Slice Orchestrator (BSSO). In this case, each domain orchestrator can use its own slice templates or blueprints.
-The BSSO can ask a domain orchestrator to create a slice that fulfills specific requirements (for example in terms of Quality of Service (QoS)). -The local orchestrator returns a list of slices that can be deployed. The mechanism of local slice or sub-slice creation is similar to the creation of a slice on-demand by an end-user. -The creation of an E2E slice as a combination of sub-slices is a preferred solution when slice creation is triggered by end-users. Herein, sub-slices are created using a parallel process; hence accelerating the E2E slice creation roll-out time. This solution is also actual if an intermediate domain operator does not allow to create or operate a slice by a BSSO in its domain. -This approach is more flexible and applies to the case when an existing slice is enlarged. Note that connecting (chaining) slices may affect the QoS of an E2E slice. Therefore, a process of how to orchestrate slices should be taken into account.  include multiple sub-domains operated by multiple operators and providers, e.g., telecom operators, MVNOs, and cloud providers. In the architecture, slices are deployed on top of various configurations of the infrastructure, where flexible configurations are possible due to the fact that resources are virtualized (i.e., dedicated and isolated) for a specific slice.
Furthermore, the work in [28] gives an example of a multidomain slice, which is composed of three segments each covering a distinct administrative domain. In that case, each domain belongs to a different actor of the business model. It is proposed to employ a separate E2E slice coordinator at the system level in order to assure functional inter-domain coherency. The cross-domain coordinator aligns cloud and networking resources across federated domains and carries out life-cycle management operations of a multi-domain slice. It also establishes and controls inter-domain transport layer connectivity to assure the expected performance.

IV. DEDICATED 5G SLICING BUSINESS MODELS FOR IoT AND IoV
The focus of this section will be on the OBMs that constitute a part of a general IoT ecosystem and are in particular related to IoT and IoV/V2X applications. In what follows, we first identify roles, actors, and interactions. Then specific aspects related to the support of 5G slicing are discussed.

A. INTERNET OF THINGS
An IoT ecosystem is a network of organizations/actors which develop and exploit IoT products and services. The interacting actors are in both competition and cooperation status.
To present the BM for an IoT ecosystem, a role-based model is the most flexible approach. To do so, four major roles in an IoT ecosystem need to be identified and distinguished [29]. That is, (a) the development role of a technical solution for an IoT system; (b) the operational role in system functioning and exploitation to serve users; (c) governance and support; and (d) the non-technical activities of the system. Among them, the roles defined in (b) and (c) belong to the OBM.
Several other entities that do not belong to the OBM can also be involved in the IoT system development. These actors include mechanical developer, electronic hardware developer, electronics manufacturing service provider, software developer, and data processing solution developer. Furthermore, these actors develop their solutions based on the support offered by component supplier, test provider, support provider for software and data development, and data broker.
An IoT OBM can include three entities/actors, i.e., end users, IoT service provider(s), and (probably) product manufacturer(s), with their roles clarified below. The support resources are assured by a network service provider, computing provider, and support service provider. Keep in mind however that in practice an actor may play several roles.
A general model proposed in [28] defines two additional roles, acting during the development phase of the IoT system, namely, IoT client advisor and IoT contractor. However, to explore their roles is beyond the scope of this article.

1) ROLES IN THE IoT OPERATIONAL BUSINESS MODEL
An IoT OBM assumes the existence of six major actors, i.e., a Computing Provider (CP), NSP, Product Manufacturer (PM), SP, support and service provider, and user. Their respective roles are explained below.
• The CP provides the IT infrastructure (e.g., computing power, data storage, and basic software) necessary to run and operate the IoT solution and its parts. The computing provision can be performed either in a central or a distributed manner. Frequently, this role can be taken by the PM or by a third-party computing (cloud) provider. The computing parts setup can be provided on premises at the PM, on shore, at the IT outsourcing company, or as a cloud service (IaaS or PaaS). The PaaS solution can be combined with a software and data solution platform.
• The NSP assures connectivity for the IoT enabled products. The NSP services are often provided by a telecom entity (cellular, low-power small or large area). For short range wireless technologies and internal networks, the NSP role is often embedded in the PM organization or the utilizer's organization. Connectivity technologies are very diverse, depending on the geographic scale, application type, required bandwidth and response time, complexity, cost, security guarantees, etc.
• The PM of the physical IoT-enabled product is also referred to as the Product Owner or the IoT Solution Owner. Its role can be performed by well-established companies with existing non IoT-enabled products on the market, or start-ups trying to enter the market with new products being born as IoT-enabled. The PM may itself start an IoT enablement as part of the product development process, or based on a user request. The PM may have some of the capabilities needed to IoT-enabled product but may need to source the rest of the capabilities from the IoT ecosystem. The PM may take the role to offer itself IoT services and in such a case it will be a part of the OBM.
• The SP utilizes the capabilities provided by an IoT-enabled solution to offer services to users. The SP may take also the PM role, or SP and PM could be separated. For example: -Split roles: A municipality (user/utilizer) purchases new IoT-enabled waste containers from a PM and allows a disposal company which offers waste disposal services to serve as an SP. -Combined roles: A PM offers a service for predictive maintenance on its machinery through IoT-enablement.
• The user avails and/or operates the IoT enabled product or service. A user might be: -An end-user who directly consumes the IoT enabled product or service. An example of such a user can be a citizen who uses an IoT enabled trash bin. -A utilizer who facilitates an IoT enabled product or service into use. The utilizer can either purchase off-theshelf products/services or request new products/services from the PM. An example can be a municipality ordering IoT enabled trash bins.

2) SUPPORT OF 5G SLICING FOR IoT APPLICATIONS
Among the three fundamental service classes for 5G, i.e., eMBB, mMTC, and Ultra-Reliable Low Latency Communications (URLLC), mMTC is the one which fits best for supporting IoT applications that are characterized by low requirements in terms of latency and throughput. These service classes are referred to as three major 5G user cases by the 3GPP and each of them has a different set of service requirements. 5G can create solutions within an E2E network slice for each service scenario (e.g., autonomous vehicle slice, smart health slice, industrial automation slice, environment monitoring slice, etc.) In particular, mMTCtype slices could well serve those IoT applications that require a high number of end devices for machine-tomachine communications. For IoT connectivity especially in scenarios where large or huge numbers of IoT devices exist, both licensed band based connections and unlicensed band based connected could be supported. For certain categories of IoT/V2X applications requiring high data rates, eMBB-type slices may be preferable, as presented later in Subsection V-B.
Considering the actors and roles in the IoT OBM presented above, the creation of network slices becomes essential for NSPs and/or PMs. A slice provider can offer NSaaS to create customized network slices to users. This approach generates a new business model for MNOs compared with the BMs without slicing [30]. Network slicing can improve resource utilization efficiency and scalability by adjusting the allocation of network resources among slices.

B. INTERNET OF VEHICLES
IoV is a network with connected components (vehicles) which are intelligent moving objects with sensing, computing, storage capabilities, and control units. Vehicles can connect to other vehicles, to road side units, charging/gas stations, the Internet, pedestrians, via V2X communications. Vehicles can play client or server roles, take big data services, leading to numerous new IoV applications, from assisted/autonomous driving, platooning, secure information sharing and learning, to traffic control and optimization. IoV is an extension of V2X, aiming to create a global network of vehicles -enabled by various wireless access technologies. It involves the Internet and includes heterogeneous access networks. IoV extends traditional basic automobile functions like vehicle driving and safety to novel target domains such as enhanced traffic management, automobile production, repair and vehicle insurance, road infrastructure construction and repair, logistics and transportation, etc. IoV can be regarded also as a dedicated use case of IoT, dealing with intelligent terminals and components such as vehicles (and among them some are autonomous).
The complexity of V2X/IoV applications demands for strong support from an advanced infrastructure. The 5G slicing technology is a promising candidate for enabling V2X/IoV services. Accordingly, 5G V2X/IoV BMs determine the roles, responsibilities, and interfaces of the entities and after defining the use cases, allow identification of system requirements and architecture design. Concerning V2X BMs, it is recognized that there still lacks some insights into the required roll-out conditions, roles of different stakeholders, investments, business models, and expected profit for Connected and Automated Mobility (CAM) services (see a business feasibility study for 5G V2X deployment by the 5G-PPP [31]). On the other hand, the general BMs developed for 5G sliced networks should be adapted and refined in order to serve V2X/IoT system requirements.
The 5G-PPP Automotive Working Group [31] has defined a general 5G V2X BM, capturing both operational features and business relationships. It identifies the following key stakeholder categories involved in the deployment of 5G V2X technologies (shown in Figure 4), i.e., 5G industry (network operators, network and device vendors); automotive industry; Standards Developing Organizations (SDOs); road infrastructure operators; policy makers, and users.
The four actors that belong to the V2X OBM as well as their roles are outlined below.
• 5G industry includes any general business activity or commercial enterprise developing or using 5G, or providing 5G-related services, e.g., MNOs, telecom vendors, cloud providers, device providers, software developers, etc.
• Automotive industry includes car Original Equipment Manufacturer (OEMs) (e.g., car manufacturers), component manufacturers and tier-1 suppliers, CAM service providers, high definition map providers, and other automotive-specific technology providers. It can also include other services such as vehicle logistic sectors. This category brings automotive expertise and services (including mobility services) to customers (business and consumers).
• Road Infrastructure Operators (RIOs) are national or regional entities (public/private) performing deployment, operation, and maintenance of physical road infrastructure. They may also manage road traffic operations, own, or operate toll systems, etc.
• Users can be drivers, vehicle owners, passengers, or pedestrians.
In Figure 4, several interactions between stakeholders are represented (with their details described in [31]). Herein, R1 provides users with the authorized regulations to be followed; R2 collects feedback from users in order to define the requirements and features of the new products, functionalities and services. R3 represents the regulation framework by policy makers to be followed by automotive industry as well as the feedback; R4 means that users buy products and services from the 5G Industry and provide feedback; R5 represents intercooperation, allowing design a 5G V2X technology which meets the system and component level needs; R6 represents the regulations and feedback between policy makers and the 5G Industry; R7 indicates that SDOs have to consider regulatory conditions in standards development; R8 represents that SDOs define the standards to be implemented for 5G deployments; R9 means that RIO may participate in the deployment of 5G V2X and provide or facilitate licenses or other infrastructure requirements.
In the meantime, several research projects that target at 5G based V2X systems have proposed BMs similar to the one developed by the 5G-PPP. For example, the 5GCAR [32] project identifies a BM in which the four actors presented above can interact according to operational scenarios. Those stakeholders may assume different roles in V2X applications with the support of network slicing features.
-A tenant entity rents and leverages 5G connectivity. Note that RIOs, OEMs, or other organization may also take this role. -An MSP provides services to different tenants with 5G dedicated slices for customized services. -A 5G infrastructure provider can be divided into cloud and RAN providers, and they offer the elements needed for the MSP to implement its slices. -A non-V2X (supplementary) service provider can offer passenger-targeted services such as enhanced infotainment, mobile office, etc.
On the other hand, although a general 5G slicing OBM may be mapped approximately one-to-one onto the V2X OBM, the dynamic environment caused by vehicle mobility introduces additional challenges for service provisioning. As an effort from the 3GPP, two documents, TS 22.186 and TR 23.786 [33], [34], have elaborated network slicing for V2X systems. It is recommended to develop dedicated V2X slices, considering that the basic reference slices for other traffic types such as eMBB, mMTC, and URLLC, in their original forms, are incapable of sufficing V2X requirements to a satisfactory level.
As of today, constructing dedicated 5G V2X slices is still a challenging task since it requires multi-access and edgeoriented 5G network infrastructures. Appropriate priorities should be assigned to different classes of traffic (e.g., in dedicated network slices for V2X safety applications, the V2X traffic type should be prioritized over other network traffic types). A slice provider should be able to handle intra-and inter-MNO mobility seamlessly through swift slice resource reconfiguration and inter-operator slice orchestration.

V. SOLID-B5G PROJECT SOLUTIONS
In this section, we present the vision, business models, and solutions proposed in our ongoing project -SOLID-B5G which focuses on developing network slicing solutions for IoV/V2X and maritime IoT applications.
A. SOLID-B5G VISION 5G slicing facilitates a powerful and flexible networking platform for a wide range of applications. In particular, massive IoT (mIoT) applications specifically in IoV/V2X and maritime sectors, that are the main targets of the SOLID-B5G project, can be well served by the 5G slicing technology. Among the three use cases mentioned above, the SOLID-B5G project focuses on mMTC/mIoT and URLLC by developing decentralized solutions based on Multi-access Edge Computing (MEC) combined with network slicing and applying them to IoV/V2X and maritime applications. Novel massive multiple-input and multiple-output (mMIMO) based radio access mechanisms at the network edge will also be developed as part of this project. Figure 5 illustrates a high-level view of the proposed system architecture which addresses two unique use cases for mMIMO based ubiquitous IoT data collection and network slicing enabled service provisioning for IoV/V2X and maritime applications.

B. SOLID-B5G BUSINESS MODELS FOR IoV/V2X APPLICATIONS
The operational business actors involved in SOLID-B5G studies are selected by considering the scenarios identified in the project, particularly based on service descriptions related to IoV/V2X applications. That is, vertical services and use cases for safety and traffic efficiency of V2X slices as well as for autonomous driving. More specifically, two types of dedicated slices, non-URLLC and URLLC, are considered, for two categories of applications: • Non-URLLC slice for traffic efficiency and auxiliary services. This slice targets at non-time-critical V2X/vehicle-to-pedestrian (V2P) applications for instance periodic messages containing alerts, road condition update, weather forecast, kinematics parameters, entertainment applications, etc. For example, for transferring messages between two vehicles directly or via a road side unit, the maximum latency is 100 ms [35]. High reliability should be supported without requiring application-layer message retransmissions, but no concrete value is given in 3GPP TS 22.185 [35]. mMTC slices can support services where vehicles can sense and learn environmental changes from built-in sensors deployed in cars or within infrastructure. mMTC is also useful within a dense connected environment to support non-delay-sensitive V2X applications (e.g., dynamic ride sharing, software update) or even to provide more data for safety-related applications [36].
• URLLC slice for safety and autonomous driving. URLLC slices will play a vital role for intelligent transportation including automated driving, road safety, and traffic efficiency services, etc. These slices need to satisfy the requirements that are far stricter than those for non-URLLC applications, for instance collision warning, automatic cruise control, vulnerable road users VOLUME 9, 2021 FIGURE 5. A general view of the SOLID-B5G system architecture including RAN for IoV/V2X and maritime applications, 5G core, and satellite connections.
safety alert. In such cases, vehicles may drive very close to each other (e.g., platooning) and at higher speeds, and surrounding environments may change dynamically. For highest degree of automation for platooning, the maximum E2E latency is 10 ms and the reliability requirement is 99.99% [33]. For emergency trajectory alignment between vehicles supporting V2X application, the maximum E2E latency and reliability requirements are 3 ms and 99.999% respectively [33]. Vehicles can benefit from the information they receive from road side units or other vehicles. Typical use cases can be automated overtake, cooperative collision avoidance, and high-density platooning, which require an E2E latency of 5∼10 ms and a block error rate of ∼10 −5 [37].
On the other hand, eMBB-type slices can also be applicable to V2X applications, e.g., when high data rates are needed, for extended sensor groups or sharing high-precision video as in the case of remote driving. eMBB slices can serve vehicles on the highway with heterogeneous traffic requirements, e.g., slices for autonomous driving safety messages (URLLC services), infotainment and video streaming (non-URLLC services). eMBB can also serve non-safety applications such as infotainment and multimedia services.
In a multi-domain multi-operation environment, it is possible that multiple operators or tenants share a non-URLLC slice based on the resources provided by a common 5G infrastructure provider. For URLLC services supporting safety and autonomous driving, a dedicated slice is for each operator is preferable.
In the rest of this subsection, we identify actors for the envisaged IoV/V2X applications and explore their roles.

1) CATEGORIES OF ACTORS
Considering the general models presented in the previous subsections and on V2X/IoV supported by 5G technologies, the following categories of actors are included in the SOLID-B5G OBM.
• 5G industry. The same as presented in Subsection IV-B.
However, the services provided will be based on connectivity over dedicated slices supporting a given set of high level V2X/IoV applications. Usually, such an actor (e.g., MNO) will own and manage the network infrastructure (RAN, backhaul, and CN on top of which it can create slice instances. When MEC is adopted, the management and control of MEC could be also a task of this actor.
• Automotive Industry. The same as presented in Subsection IV-B.
• RIOs. In addition to the ones presented in Subsection IV-B, special attention will be paid to RIOs which work on new road construction as it is more likely that IoT could be an integral part of such infrastructures supporting RAN and network connectivity.
• Users. Instead of involving the general user groups presented in Subsection IV-B, we will focus on user groups in Romania and Norway.
The precise mapping between the above categories of actors and OBM roles should be defined according to specific V2X/IoV application use cases.

2) 5G SLICING STAKEHOLDER ROLES
From the 5G slicing technology point of view, a set of roles inside the OBM will be selected. We foresee that specific roles which are similar to those proposed in [38] will apply in our case.
• End-users receive the IoV/V2X services provided by a tenant or an MSP.
• A tenant purchases and utilizes a network slice and its associated services offered by an MSP. Tenant examples are an MVNO, enterprise or any entity that requires IoV/V2X services for its business operations.
• An MSP is the main entity which provides mobile Internet connectivity and IoV/V2X services to its users. To this end, the MSP constructs dedicated network slices, and their function chains to compose IoV/V2X services. Examples of dedicated slices can be URLLC and non-URLLC defined above, or mMTC for IoT applications.
• An InP owns and manages the network or road infrastructures and offers it to the MSP, in the form of IaaS.
Similar to the general case, a larger organizational entity may combine the roles of MSP and InP. Additional optional stakeholder roles may also exist, like: • As an intermediate actor (''layer'') between an InP and MSP, a VISP designs, builds and operates a virtualization infrastructure on top of the InP-offered services, and offers its infrastructure service to the MSP.
• At a lower logical level, an NFVI supplier may provide an NFV infrastructure to its customers, i.e., to the VISP and/or directly to the MSP.
If an MNO stakeholder entity is defined, then three models are possible [39] in terms of network ownership: 1) The MNO owns and manages both RANs and a CN.
2) An MNO owns and manages the CN, whereas the RAN is shared among multiple operators (i.e., RAN sharing). 3) Only a part of the network is owned and/or managed by the MNO, while other parts are owned and/or managed by a 3rd party. (An example is given in Figure 8.) Models 1) and 2) above can be found in previous generations of cellular systems, where MNOs are operating public land mobile networks. From a 3GPP perspective, stakeholder role models 1) and 2) are the same, no matter an MNO or vertical 3rd party is involved.
In earlier generations, the basic support for the 3rd party stakeholder role model was provided via APIs which allowed minimal access to or management of network capabilities. In 5G, greater control and ownership by the 3rd party are allowed, requiring increased trust between the MNO and 3rd party. These new trust relationships are more important when network slicing is considered, (e.g., if the 3rd party is authorized to control some aspects of network slices that are owned by the MNO for providing IoV/V2X services).
When network slicing is employed, Model 3) needs additional investigation related to the trust relationships between MNOs and 3rd parties. There are four potential business relationship options [39] which impact the trust relationships for stakeholder role Model 3). 3a) An MNO provides the physical/virtual infrastructure and VNFs; and a 3rd party uses the functionality provided by the MNO. 3b) An MNO provides the physical/virtual infrastructure and VNFs; and a 3rd party manages some VNFs via APIs exposed by the MNO. 3c) An MNO provides physical/virtual infrastructure; and a 3rd party provides some of the VNFs. 3d) The 3rd party provides and manages some of the physical/virtual infrastructure and VNFs. For IoV/V2X slicing in the SOLID-B5G project, the 3a), 3b), and 3c) variants will be investigated primarily, in accordance with the system architecture. Table 2 summarizes these relationship models defined by the 3GPP [39]. Among them, Models 3c) and 3d) provide extended control for the 3rd party on the network capabilities that support its services. Accordingly, appropriate levels of security should be maintained for any communications.
Furthermore, three management role models can be considered for Models 3c) and 3d).
-The MNO manages all physical/virtual infrastructure and all VNFs including 3rd party's ones. -The 3rd party manages its own physical/virtual infrastructure and/or its own VNFs; the MNO manages the others. -The 3rd party manages physical/virtual infrastructure and/or VNFs including its own infrastructure and/or VNFs and some MNO's physical/virtual infrastructure and/or VNFs; the MNO manages the others. From the 3rd party's perspective, the latter two management role models provide stronger support for its management function and enable extended management for the MNO to coordinate with the 3rd party management. The 3rd party may use suitable APIs provided by the MNO to directly manage the VNFs as well as the infrastructure resources so that it can properly handle when their business requirements are updated. The last two role models are considered in the SOLID-B5G development for IoV/V2X dedicated slices.

C. MARITIME SYSTEMS 5G BUSINESS MODEL AND IoT CONNECTIVITY SOLUTIONS
This subsection presents the OBM for a system dedicated to IoT applications in the maritime sector, with the support of 5G slicing, which is developed in the SOLID-B5G project. The corresponding solutions for IoT connectivity with and without involving satellite networks are also outlined.
In systems dedicated to maritime applications, there are specific use cases with salient traffic and connectivity characteristics. For IoT application scenarios, there are several alternative solutions for data traffic via satellite networks (see Figure 7). In the meantime, it is also feasible to carry traffic without involving satellite links, i.e., based on High Frequency (HF) radios (see Figure 8).
For maritime users/customers, we consider ships (including cruise ships, cargo vessels, etc.), offshore platforms (e.g., oil platforms) and rigs. In such scenarios, the generated traffic type will be hybrid, composed of both Human-Type Communication (HTC) traffic and IoT/MTC traffic. For the technical solutions presented later in this subsection, we pay more attention to IoT traffic.

1) SATELLITE-RELATED 5G SLICING AND IMPLICATION ON BM
A model of satellite integration into 5G slicing system is presented in [42]. The satellite network plays the transport role between RAN and CN (however, in principle, the 5G Transport Network (TN) could be of any type). Integrating a satellite network as a TN is the simplest option to integrate a satellite or several satellites into 5G networks. Defining an API between the 3GPP management system and the TN would be sufficient to configure the adopted satellite network to handle the slice flows and backhaul data between RAN and CN. In its role of TN for 5G backhauling, the satellite network covers multiple nodes 5G New Radio (NR) nodeB (gNBs) and interconnects with various 5G user plane functions. This implies to reserve adequate resources on both ground and space equipments (e.g., satellite gateways and satellite payloads). More than the reservation and allocation of resources, the equipments need to be configured and orchestrated in a simple, automated manner. The 5G network should be able to dynamically request the establishment of a backhaul connectivity and to update it dynamically according to service requirements and traffic conditions.
The above considerations suggest an approach of having a separate business role and actor to manage the satellite network and it is adopted in the SOLID-B5G project.
A typical BM for satellite network slicing would contain the following roles and actors [42]: • A satellite slice customer is the user and tenant of a satellite slice. It could be a 5G terrestrial operator who needs backhaul 5G data, or a broker who leases multiple slices to multiple satellite slice providers in order to provide multiple connectivity to its customers, or a service provider who runs OTT services.
• Satellite slice: As a service provider owns a slice management system, it must design, run, and manage slices on the top of the satellite infrastructure. It can provide slices with different levels of flexibility to a slice customer. The types of slices and services it could offer depend on the infrastructure capabilities. The slice provider roles can be played by a Satellite Network Operator (SNO), Satellite Virtual Network Operator (SVNO), or a dedicated slice operator.
• An SNO owns the satellite space segment and the satellite VNFs or/and physical network functions provided by suppliers (e.g., Eutelsat, SES, ViaSat). These functions can be monolithic components such as satellite gateways (GWs) and satellite terminals, or be disaggregated components such as digital video broadcast modulator/de-modulator or encapsulator (e.g., iDirect, Newtec, Teamcast).
• An InSP builds, manages, and maintains a virtualized infrastructure (e.g., OVH, Scaleway). A separate entity, i.e., NFVI supplier, cooperates with InSP and provides the management system for the infrastructure; and it is usually a software company (e.g., VMWare, RedHat).
• A satellite teleport provider owns the overall infrastructure. It builds the satellite teleport and configures it according to its clients' demand. A teleport could be used by multiple SNOs or SVNOs, and it is not dedicated to a specific tenant. The teleport provider also builds and maintains a backbone between all its teleports and ensures that each one is constantly connected to its customer network. A commercial off-the-shelf hardware supplier can provide necessary components to the satellite teleport provider.
The model introduces new actors related to the NFV technology. As usual, each actor could assume one or multiple roles and it would be most likely the case. For example, Telenor is both an SNO and InSP, as shown in Figure 6. In the meantime, third party involvement for data analysis and application services is also enabled, as shown in Figure 8. Herein, satellite networks include both Geostationary Earth Orbit (GEO) and Low Earth Orbit (LEO) satellites. Figure 6 illustrates a GEO satellite, Thor 7, which is owned and operated by Telenor. Thor 7 is equipped with both Ku-band and Ka-band transponders, covering Nordic countries, and Central and Eastern Europe (for Ka-band), as shown in Figure 6b).
The E2E connection covers three segments, including on-board equipment (users, IoT devices, and local networks); backhaul network (GEO or LEO satellite based); and on-land terrestrial networks. In what follows, we present our solutions which are illustrated in Figure 7.  but with a GW connection, it is also feasible to use this kind of network when the GW is placed outdoor so that it can connect to satellite 5G radio.

Summary of IoT Connectivity:
There are three options for IoT connections via satellites. That is, (1) IoT/MTC devices with 4G/5G cellular capability, e.g., Narrow-Band IoT (NB-IoT), are connected directly to a gNB, and then the satellite backhaul (the upper part of solutions (a)-(d)); (2) Direct IoT connections to LEO satellites for devices located outdoor (the lower part of solutions (a)-(d)); and (2) Connecting to satellite networks via a GW (solutions (e)-(f)).
Note further that in case of IoT connections without a GW, some reduction of data is often performed directly on an IoT device itself. For a solution where IoT devices are connected to 5G radio directly via satellite networks, local MEC on-board will not be possible. In Figure 7, we denote the core network by EPC and it would also be a 5G Core (5GC) network when available. For all solutions except (b), EPC/5GC and MEC could be co-located on-board or on-land.

3) HF RADIO BASED SOLUTIONS FOR MARITIME IoT APPLICATIONS
Considering a salient feature of IoT applications which is characteristic of sporadic traffic and small packet sizes, we present here another maritime IoT solution that does not rely on a satellite. Figure 8 illustrates a commercial solution developed by Telenor Maritime, branded as WaveAccess, which is based on wireless mesh networking through HF radios which are mounted on-board.
WaveAccess provides a subscription based IoT solution including collecting, processing, and access of vessel data with a two-way connection range up to 10000 kilometers. The radios are operated on the frequency of 1.5-30 MHz, providing data rates up to 236 kbps.
WaveAccess supports multiple standards for real-time data collection on-board, collection of data from multiple sources simultaneously, edge processing for managing and prioritizing data already at vessels, and real-time access to important data on-shore.

VI. NETWORK SLICING CHALLENGES FOR B5G/6G
5G cellular networks significantly improve communication technologies beyond 4G with respect to a variety of services/applications supported, number and kinds of terminals connected (for both HTC and MTC/IoT traffic), user experience (data rate and latency), support of dynamic traffic, processing capabilities, integration with cloud/edge computing, IoV/V2X support, energy consumption, etc.
However, 5G has limitations with respect to the needs of the future super-smart society. As such, beyond 5G or Sixth Generation (6G) networks will play a major role to resolve the challenges by providing new communication and computing services, network capacity, and ultra-low latency communications.
In what concerns 6G networks, the 6G Vision for 2030 [43]- [46] implies that a super-smart society will be data-driven, served by near instant, with unlimited wireless connectivity. The main goals of 6G include: • To meet novel network demands (e.g., ultra-high reliability, ultra-high capacity and efficiency, and ultra-low latency) in a holistic fashion, satisfying the new needs of economic, social, technological, and environmental context of the 2030 era.
• Integration of the space, aerial, terrestrial, and maritime communications into a robust network.
• Implementation of high resolution imaging and sensing, wearable displays, mobile robots and drones, specialized processors, distributed Artificial Intelligence (AI), haptic communication.
5G network slicing supported by SDN and NFV will continue to play a vital role in 6G. Other characteristics related to networking aspects of 6G include service based architectures; cognitive service architectures; cell-free operation; and ubiquitous cloud/fog/edge computing.
Related to network slicing for 6G, several challenges will have to be addressed, such as: • Slice isolation. To guarantee the service quality of each slice, different areas of isolation should be realized, including traffic, bandwidth, processing, and storage. The main challenge is the management and control of resources as such functions require to accommodate different isolation mechanisms across multiple domains. The isolation mechanisms significantly rely on SDN and NFV functionalities, which are not yet fully mature.
• Lack of standards for 6G slicing. There is not yet a final standardized network slice architecture. Integration of the space, aerial, terrestrial, and maritime communications into a robust network with slicing will raise a major challenging task.
• Dynamic slice creation and management. Efficient dynamic slice creation and deletion are necessary, while preserving isolation (performance, security) of slices. A network slice should be able to scale dynamically with the varying load and efficient sharing is necessary. Furthermore, life cycle management of network slices is a critical problem, especially in a multi-domain, multitenant and multi-operator environment.
The SOLID-B5G project will extend its studies in the beyond 5G area, especially towards two directions: • Integration of space, terrestrial, and maritime communications into a flexible and robust network (in accordance with the project objectives); • Dynamic slice creation and management which are necessary in high mobility IoV/V2X applications.

VII. CONCLUSION
This article revisited the ecosystems and business models for 5G slicing systems and then defined the BM for a novel European research project, SOLID-B5G. The definition of actor/stakeholder roles and their interactions (at both business and technical levels) have been presented, while considering some basic models proposed by the 3GPP and 5G-PPP. It has been shown that several non-convergent approaches exist in the literature, related to the definition of an ecosystem and business model. This study considered a business model as a part of a more general ecosystem. While the general ecosystems could involve a large range of entities/organizations, the focus of this article has been on 5G operational business models, limited to those actors who are active and interacting for real-life system deployment and operation. A comparative overview of different BMs for 5G sliced systems has been performed. The final part of this article developed a selection among some tailored BM configurations, adapted for dedicated slices, aiming to serve IoT, IoV/V2X, and maritime vertical applications. Our technical solutions for IoT connectivity in maritime applications have also been outlined and these solutions are currently being implemented within our ongoing project. Finally, some open research issues from the perspective of future 6G have been addressed and new challenges are identified.

APPENDIX LIST OF ABBREVIATIONS
See Table 3.