CN114586398A

CN114586398A - Leaser management

Info

Publication number: CN114586398A
Application number: CN201980101305.2A
Authority: CN
Inventors: 平静; I·亚当; A·安德里亚诺维; O·珀拉科瓦斯基
Original assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Current assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Priority date: 2019-10-14
Filing date: 2019-10-14
Publication date: 2022-06-03
Also published as: WO2021072594A1

Abstract

Embodiments of the present disclosure relate to leaser management. Based on the determination of the service requested by the leaser, the first device generates a mapping between the leaser and the requested service. The first device determines a service profile for the requested service based on the mapping and a leaser profile for the leaser, the leaser profile including information for supporting the service for the leaser, the service profile including service requirements for the requested service. The first device provides the requested service to a second device associated with the leaser based at least in part on the service profile.

Description

Leaser management

Technical Field

Embodiments of the present disclosure relate generally to the field of telecommunications, and more particularly, to methods, apparatuses, devices, and computer-readable storage media for tenant management.

Background

Mobile networks are becoming increasingly important for the continued digitization of business and everyday life, as well as the transition to the interconnected society. In addition, fifth generation (5G) networks are expected to provide unique opportunities for operators, addressing and providing new business models for consumers, businesses, verticals, and third party partners. A large number of different customer types, each requiring a specific communication solution, are inherently intractable due to the widely different requirements that need to be addressed at any point in the deployment.

Dedicated physical networks would be an obvious solution, as they can be perfectly customized and adapted to service or service specific needs and provide maximum performance. However, in many cases, the resources of such networks are not fully utilized most of the time and over large geographic areas. Thus, there is a need for a common infrastructure platform that is shared among multiple enterprises. In order to achieve the above objective, a 5G new air interface wireless multi-service adaptive network architecture (norm) has proposed a multi-service multi-tenant system architecture based on network slice.

Disclosure of Invention

In general, example embodiments of the present disclosure provide solutions for leaser management across multiple domains and layers.

In a first aspect, a first apparatus is provided. The first device includes: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the first apparatus to generate a mapping between the leaser and the requested service based on the determination of the service requested by the leaser; determining a service profile for the requested service based on the mapping and a leaser profile (profile) for the leaser, the leaser profile including information for supporting the service for the leaser, the service profile including service requirements for the requested service; and providing the requested service to a second device associated with the leaser based at least in part on the service profile.

In a second aspect, a second apparatus is provided. The second device includes: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the second apparatus to send a lease request for a service to the first apparatus; and receiving the requested service from the first device, providing the requested service based at least in part on a service profile of the requested service, the service profile including service requirements for the requested service, the service profile determined based on a mapping between the renter and the requested service for the renter and a renter profile for the renter, the renter profile including information for supporting the service for the renter.

In a third aspect, a method is provided. The method comprises the following steps: generating, at the first device, a mapping between the leaser and the requested service based on the determination of the service requested by the leaser; determining a service profile for the requested service based on the mapping and a leaser profile for the leaser, the leaser profile including information for supporting the service for the leaser, the service profile including service requirements for the requested service; and providing the requested service to a second device associated with the leaser based at least in part on the service profile.

In a fourth aspect, a method is provided. The method comprises the following steps: sending a lease request for a service to a first device and at a second device; and receiving a request service from the first device, the request service being provided based at least in part on a service profile of the request service, the service profile comprising service requirements for the request service, the service profile being determined based on a mapping between the renter and the request service and a renter profile for the renter, the renter profile comprising information for supporting services for the renter.

In a fifth aspect, there is provided an apparatus comprising: means for generating, at the first device, a mapping between the leaser and the requested service based on the service requested by the leaser; means for determining a service profile for the requested service based on the mapping and a leaser profile for the leaser, the leaser profile including information for supporting the service for the leaser, the service profile including service requirements for the requested service; and means for providing the requested service to a second apparatus associated with the leaser based at least in part on the service profile.

In a sixth aspect, there is provided an apparatus comprising: means for sending a lease request for a service to a first device and at a second device; and means for receiving a request service from the first device, the request service being provided based at least in part on a service profile of the request service, the service profile comprising service requirements for the request service, the service profile being determined based on a mapping between the renter and the request service and a renter profile for the renter, the renter profile comprising information for supporting services for the renter.

In a seventh aspect, there is provided a non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the method according to the above third aspect.

In an eighth aspect, there is provided a non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least a method according to the fourth aspect above.

It should be understood that the summary is not intended to identify key or essential features of various embodiments of the disclosure, nor is it intended to be used to limit the scope of the disclosure. Other features of the present disclosure will become readily apparent from the following description.

Drawings

Some example embodiments will be described with reference to the accompanying drawings, in which:

FIG. 1 shows a schematic diagram illustrating an example architecture for a multi-tenant and multi-service 5G system;

FIG. 2 illustrates an example environment in which embodiments of the present disclosure may be implemented;

FIG. 3 shows a flowchart illustrating an example process for leaser management;

fig. 4 illustrates an example architecture according to some example embodiments of the present disclosure;

fig. 5 shows a flowchart illustrating an example process for leaser management, in accordance with some example embodiments of the present disclosure;

fig. 6 shows a flow diagram of an example method according to some example embodiments of the present disclosure;

fig. 7 shows a flow diagram of an example method according to some example embodiments of the present disclosure;

FIG. 8 shows a simplified block diagram of an apparatus suitable for implementing embodiments of the present disclosure; and is

Fig. 9 illustrates a block diagram of an example computer-readable medium in accordance with some embodiments of the present disclosure.

Throughout the drawings, the same or similar reference numerals denote the same or similar elements.

Detailed Description

The principles of the present disclosure will now be described with reference to a few exemplary embodiments. It is to be understood that these examples are described solely for the purpose of illustration and to aid those skilled in the art in understanding and practicing the invention, and are not intended to limit the scope of the present disclosure in any way. The disclosure described herein may be implemented in a variety of ways other than those described below.

In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs.

References in the present disclosure to "one embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It will be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term "and/or" includes any and all combinations of one or more of the listed terms.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises," "comprising," "has," "having," "includes" and/or "including," when used herein, specify the presence of stated features, elements, and/or components, but do not preclude the presence or addition of one or more other features, elements, components, and/or groups thereof.

As used in this application, the term "circuitry" may refer to one or more or all of the following:

(a) hardware-only circuit implementations (such as implementations in analog-only and/or digital circuitry) and

(b) a combination of hardware circuitry and, for example (as applicable), software:

(i) combinations of analog and/or digital hardware circuitry and software/firmware, and

(ii) any portion of the hardware processor is combined with software (including a digital signal processor, software and memory that work together to cause a device, such as a mobile phone or server, to perform various functions), and

(c) hardware circuitry and/or a processor, such as a microprocessor or a portion of a microprocessor, requires software (e.g., firmware) for operation, but software may not be present when operation is not required.

The definition of the circuit applies to all uses of the term in this application, including all uses in any claims. As another example, as used in this application, the term circuitry also encompasses implementations of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. For example, the term circuitry, if applicable to a particular claim element, also encompasses a baseband integrated circuit or processor integrated circuit for use in a mobile device or similar integrated circuit in a server, cellular network device, or other computing or network device.

As used herein, the term "communication network" refers to a network that conforms to any suitable communication standard, such as 5G, Long Term Evolution (LTE), LTE-advanced (LTE-a), Wideband Code Division Multiple Access (WCDMA)), High Speed Packet Access (HSPA), narrowband internet of things (NB-IoT), and the like. Further, communication between terminal devices and network devices in a communication network may be conducted according to any suitable generation communication protocol, including, but not limited to, first generation (1G), second generation (2G), 2.5G, 2.75G, third generation (3G), fourth generation (4G), 4.5G, future fifth generation (5G) communication protocols, and/or any other protocol currently known or developed in the future. Embodiments of the present disclosure may be applied in various communication systems. In view of the rapid development of communications, there will, of course, also be future types of communication techniques and systems that may embody the present disclosure. And should not be taken as limiting the scope of the disclosure to only the above-described systems.

As used herein, the term "service provider" may be considered an entity for generating a service to be accessed by a service consumer. For example, a service provider, which may be referred to as an authentication server function (AUSF) defined in a 5G core network function, generates authentication services for terminal devices (e.g., User Equipment (UE)) for access by access and mobility management functions (AMFs). The terms "service provider" and "service producer" may be used interchangeably herein.

As described above, a multi-service and multi-tenant capability system architecture based on network slices has been proposed. Fig. 1 illustrates a schematic diagram 100 illustrating an example architecture for a multi-tenant and multi-service 5G system. In fig. 1, the exemplary 5G system 110 may be divided into three levels, namely a telecommunications service level 120, a logical network level 130, and an infrastructure level 140. The infrastructure level 140 may include a 5G infrastructure 141, such as various physical devices and software deployed thereon. The virtual network 131-133 of the logical network level 130 may provide network slicing to support the various services 121-124 of the telecommunication service level 120. The various entities may be users or consumers of the 5G system 110, including but not limited to energy entities 111, health entities 112, government entities 113, and automation entities 114.

As shown in fig. 1, in a 5G system and possibly any other communication system, vertical industry development is allowed and participation in business models and digital economies is fast and cost-effective at the same time. It not only has the characteristics of ultra-reliability, low time delay, extreme flexibility, dynamic adoption of network traffic on demand, but also significantly increases complexity due to the characteristics of multiple tenants, multiple network slices, multiple domains, multiple layers, and resource sharing. Therefore, in this complex ecosystem, it is difficult to secure and protect resources of the leaser.

Furthermore, the flexible 5G system allows a renter to integrate its own services, functions, networks or resources with the producer/provider's services, functions, networks or resources to build an end-to-end service. In this way, the renter can take advantage of existing resources and expertise, and then reduce costs and increase efficiency. On the other hand, however, it increases the complexity of the 5G system and poses a threat surface on the system.

The European Telecommunications Standards Institute (ETSI) Network Functions Virtualization (NFV) group has introduced a resourceGroupId to represent tenants that allow the NFV management and orchestration system to create and separate virtualized resources for multiple tenants, but only in a single virtualization domain. Many clouds and service providers support multiple tenants, but also in single domains and monolayers.

In the fifth service and system aspect (SA5) working group of the third generation partnership project (3GPP), research projects (SI) were created to study leaser aspects in 5G networks and network slices, and recently approved as a normative specification. However, SI and WI only address the leaser identification and access management data for each leaser in the 3GPP management domain. The leaser isolation problem across multiple tiers and domains is not addressed. In particular, the SI/WI is proposed to have the renter identification or information as part of the network slice object or service profile. This approach may expose the leaser information to the resource layer and worse, reveal the leaser information to other domains.

The 5G security working group of the global system for mobile communications association (GSMA) network security Fraud and Security Architecture Group (FSAG) also presents a statement of the security aspects of multi-tenants in 5G networks and network slices, but no solution has been proposed so far.

The performance and security of the multi-tenant 5G system are essential conditions for large-scale commercialization of 5G networks. Therefore, there is a need for the management of leasers to ensure the performance and security of multi-leaser systems.

According to an embodiment of the present disclosure, a solution for leaser management is presented. In the present disclosure, a mapping between a leaser and a service requested by the leaser is maintained by the respective service provider. In this way, the leaser profile of the leaser and the service profile of the requested service are associated with each other via the mapping. The service provider may provide the requested service according to a service profile determined based on the mapping and the leaser profile. The mapping may be implemented as an entry (entry) in a mapping table or leaser matrix. Multiple tenants and/or services can be efficiently and securely managed.

Embodiments of the present disclosure can be used to manage multiple tenants and their resources across multiple tiers and domains, and allow tenants and their resources to be protected in a multi-domain and multi-tier framework. In addition, the solution also allows the renter function running in the provider/producer scenario to securely access the renter's private resources on demand.

The principles and implementations of the present invention are described in detail below with reference to fig. 2-5. FIG. 2 illustrates an example environment 200 in which embodiments of the present disclosure may be implemented. The environment 200 includes a service provider 210 that can provide a service 214 to a renter 220. The service provider 210 may maintain a service profile 213 for the service 214 requested by the renter 220 and a renter profile 212 for the renter 220. Service provider 210 may be within an administrative domain (e.g., administrative domain a).

To manage the leaser 220 and potentially other leasers (not shown), the service provider 210 maintains a mapping table 211, which may also be referred to herein as the leaser matrix (TM). The mapping table 211 may map the leases of the service provider 210 to services requested by the respective leases and vice versa. For example, the mapping table 211 includes an entry or record that maps the leaser 220 to the request service 214. It is understood that one leaser may have multiple services, but one service can serve only one leaser. Thus, using mapping table 210, a leaser (e.g., leaser 220) can be mapped to zero, one, or more services, while one service (e.g., service 214) can only be mapped to zero or one leaser.

The mapping table 211 may map the leaser 220 to the service 214 by mapping the identity of the leaser 220 to the identity of the service 214 or the identity of the service profile 213. In some example embodiments, the identity 220 of the renter may be a renter identity (renter ID) of the renter 220. In some example embodiments, the identification of the service 214 may be a service identification (service ID) of the service 214.

A service (e.g., service 214) may be implemented using resources that may be shared by multiple services. A service and resource, as used herein, may be at least one of an application, a communication service, a network slice subnet, a mobile network, a transport network, a network service, a virtual network function, a microservice. Furthermore, a resource may also be a virtual machine, container, hardware, and the like.

Service profile 213 may include service requirements for service 214, which may be used to deploy, configure, monitor, update, extend resources of service 214. Service requirements may include, for example, latency, availability, isolation, coverage, resiliency, security, and the like. The service profile is associated with a resource.

The renter profile 212 can include various information for the renter 220 including, but not limited to, the renter character, the renter access information, the renter policy (e.g., security policy) required to support the services of the renter 220, and any other suitable information. As used herein, an object corresponding to a renter may be referred to as a renter object. The leaser profile 212 may be associated with the leaser object if the leaser object of the leaser 220 is managed in the same management domain (i.e., management domain a). Otherwise, only the leaser profile 212 including the information that needs to be known may be imported from other administrative domains.

In the example environment 200, the leaser profile 212 and the service profile 213 are associated with each other via a mapping table 211 rather than directly to each other. Although only a tenant profile 212 and a service profile 213 are shown, mapping table 211 may be associated with a set of tenant profiles and a set of service profiles. There may be one or more leaser matrices in administrative domain a. The leaser matrix may be a separate object and may be part of the leaser object if the leaser object is managed in the same management domain.

Processing/function blocks (not shown) in the administrative domain a map information (e.g., policies) in the leaser profile 212 to leaser-specific attributes/requirements of the associated service profile 213 and manage and orchestrate the resources of the service 214 of the leaser 220 according to the attributes/requirements of the service profile 214, as described below.

In some example embodiments, environment 200 may include a tenant anchor (anchor)215, which is a function block that brokers messages between service provider 210 and tenant 220 for the case where a service in the service provider's 210 administrative domain (e.g., service 214) needs to access the resources of the tenant 220 in the tenant domain. The leaser anchor 215 may be an agent deployed and running in the context/execution environment of the management domain of the service provider 210. Through the renter anchor 215, the service provider 210 has access only to the renter 220, in other words, it has access to the direct renter, but not to the renter of the renter 220.

In some example embodiments, service provider 210 or a process/function block in administrative domain a may be a leaser of a service/resource provided by another domain, such as service provider 230. In such an example embodiment, service provider 210 may be considered a leaser for service provider 230 and request service 234 from service provider 234.

Service provider 230 may maintain mapping table 231, leaser profile 232 for service provider 210, and service profile 233 for request service 234. Mapping table 231, leaser configuration file 232 and service configuration file 233 are similar to mapping table 211, leaser configuration file 212 and service configuration file 213, respectively. Service provider 230 may be within administrative domain B. The leaser information for the leaser 220 is not known to any entity in the administrative domain B. In some example embodiments, the service provider 230 may access resources in administrative domain A via the leaser anchor 235, similar to the leaser anchor 215.

It should be understood that the renter and the service provider are relative concepts. The service provider may be a leaser of another service provider. For example, in some example embodiments, service provider 210 may be a leaser for service provider 230. In addition, a renter may be another renter's service provider. For example, the renter 220 may provide services to another renter (not shown).

Referring now to fig. 3, a flow diagram is shown illustrating an example process 300 for leaser management. For purposes of discussion, the process 300 will be described with reference to fig. 2. The process 300 may involve the renter 220 and the service provider 210 as shown in fig. 2. While process 300 is described with respect to service provider 210, it is to be understood that the actions described with respect to service provider 210 may be performed by a device (which may be referred to as a first device) or functional block implemented at service provider 210 or otherwise associated with the service provider. Similarly, the actions described with respect to the renter 220 can be performed by an apparatus (which can be referred to as a second apparatus) or functional block implemented at the renter 220 or otherwise associated with the renter 220.

The renter 220 (e.g., a device associated with the renter 220) sends 305 a request for the service 214 to the service provider 210 (e.g., to a device implemented at the service provider 210). After determining that the leaser 220 requests the service 214, the service provider 210 generates a mapping 310 between the leaser 220 and the requesting service 214.

In some example embodiments, the mapping may be a separate record maintained at the service provider 210. In some example embodiments, the mapping may be an entry or record of a leaser matrix, such as mapping table 211. For example, the service provider 210 may determine an identification for the renter 220 (which may be referred to as a first identification for purposes of discussion) and an identification for the request service 214 (which may be referred to as a second identification for purposes of discussion). The service provider 210 may then add a first entry to the mapping table 211, the first entry mapping the first identification to the second identification.

The identification for the renter 220 can be the renter ID of the renter 220 or any suitable identification that can distinguish the renter 220 from any other renter of the service provider 210. In some example embodiments, the identification used to request the service 214 may be, for example, a service ID of the service 214 in the case where the service 214 has been deployed. In some example embodiments, the identification for the request service 214 may be an identification of a service profile 213 associated with the request service 214.

By means of the mapping table 211 or the leaser matrix, multiple services and/or multiple leasers can be managed in a centralized manner. In some example embodiments, the mapping table 211 may also include a second entry mapping the first identification to a third identification for a further service (not shown) requested by the leaser 220. In some example embodiments, the mapping table 211 may also include a third entry that maps a fourth identification for another leaser to a fifth identification of another service requested by the other leaser.

In some example embodiments, mapping table 211 may be a separate object, for example, a separate object in administrative domain a of service provider 210. In this case, mapping table 211 may include different entries for different tenants of service provider 210, such as example table 450 shown in FIG. 4, which will be described in detail below.

In some example embodiments, the mapping table 211 may be part of another object. For example, if an object corresponding to the renter 220, also referred to as a renter object of the renter 220, is managed in the same management domain of the mapping table 211, the mapping table 211 can be part of the renter object. In this case, the mapping table 211 may maintain entries for different services for the renter 220.

Still referring to fig. 3, the service provider 210 determines 315 a service profile 213 for the requested service 214 based on the mapping (e.g., an entry in the mapping table 211) and the leaser profile 212 for the leaser 220. The leaser profile 212 includes at least information for supporting the service for the leaser 220, and the service profile 213 includes at least one service requirement for requesting the service 214. To determine 315 the service profile 213, the service provider 210 may modify or update the service profile 213 that has been generated or otherwise obtained, as described in detail below.

As described above with reference to fig. 2, the renter profile 212 defines the renter characters, the renter access information, the renter policies required for supporting the services of the renter 220, and any other information related to the renter 220. The renter profile 212 is associated with an identification for the renter 220, such as the renter ID of the renter 220.

The service provider 210 may obtain the leaser profile 212 before processing the service request from the leaser 220. In some example embodiments, the service provider 210 may generate the leaser profile 212 based on information used to support the service for the leaser 220. Such information may be extracted from a contract with the renter 220. In some example embodiments, the service provider 210 may receive a leaser profile 212 generated by another device different from the first device. For example, if the service provider 220 is an operator, the leaser profile 212 may be imported from a Business Support System (BSS).

As mentioned above with reference to fig. 2, the service profile 213 may define service requirements for the service 214 that may be used to deploy, configure, monitor, update, scale resources for the service 214 when the requesting service 214 is provided to the renter 220. Service requirements may include, for example, latency, availability, isolation, coverage, resiliency, security, and the like. The service profile 213 may be generated based on a service request from the renter 220.

To determine 315 a service profile 213, the service provider 210 (e.g., a function block) may map information, such as policies/rules, in the leaser profile 212 to the attributes/service requirements of the associated service profile 213. Existing service requirements in the service profile 213 may be updated based on information in the leaser profile 212. Alternatively or additionally, new service requirements may be added to the service profile 213 based on information in the leaser profile 212.

The service profile may include basic service requirements and leaser specific service requirements. In this case, when the service profile 213 that has been generated or obtained is updated, the basic service requirements will not be updated by the information in the tenant profile 212. Only information (e.g., policies/rules) service requirements that are relevant to the leaser-specific service requirements will be mapped from the leaser profile 212 to the service profile 213. As a result, new leaser specific service requirements may be added to the service profile 213, or the value of existing leaser specific service requirements may be updated.

The service provider 210 provides 320 the request service 214 to a second device associated with the renter 220 based at least in part on the service profile 213. For example, the functional blocks of the service provider 210 can manage and orchestrate the resources of the requesting service 214 of the renter 220 according to the attributes/requirements in the service profile 213.

In some example embodiments, the service provider 210 may access or utilize the resources of the leaser 220 through a function block (e.g., the leaser anchor 215 in fig. 2) for proxying messages between the domain of the service provider 210 and the domain of the leaser 220. The leaser anchor 215 may be an agent (of the leaser 220) that is deployed and run in the context/execution environment of the service provider's 210 domain (in this case, administrative domain a).

The service provider 210 can determine available resources of the leaser 220 for the service provider 210 (e.g., the first device) to provide the request service 214 based on the leaser profile 212. The service provider 210 may then access the available resources through a function configured for communication between the first device and the second device associated with the leaser 220.

As an example, if a leaser-specific resource is required to support the service 214 of the leaser 220 according to the service request, the service provider 210 may locate the leaser anchor 215 based on the information in the leaser profile 212 and extract information for accessing the leaser-specific resource from the leaser profile 212. The service provider 210 may then extract and associate the leaser-specific resource from the leaser 220 with a service profile 213, e.g., an access point or endpoint, represented as a resource, and access information, such as a public certificate, needed to access the leaser-specific resource.

In some example embodiments, the service profile 213 may be updated based on changes in the leaser profile 212. For example, if there is a change in the tenant profile 212, the service provider 210 may obtain or extract the service profile 213 based on a mapping, for example, in the mapping table 211. The service provider 210 can then update the service profile 213 based on the changes in the leaser profile 212. Service provider 210 may provide request service 214 based on the updated service profile. It should be understood that other service profiles associated with the tenant profile 212 via the mapping table 211 may also be updated based on changes in the tenant profile 212.

For example, if the renter profile of the renter changes, the service provider 210 may determine the identity of the service mapped to the renter identity based on the mapping table 211 and obtain or extract a service profile identified by or associated with the identity for the service. The service profile may then be updated based on the changes in the leaser profile. Service provider 210 may further update the service associated with the service profile accordingly.

In some example embodiments, the mapping between the leaser 220 and the requesting service 214 may be removed if the associated leaser profile 212 is removed or the associated service profile 213 is removed.

In some example embodiments, service provider 210 in administrative domain a may be another service provider in another administrative domain, e.g., a leaser managing services/resources provided by service provider 230 in domain B. The service provider 210 can determine the available service providers for providing the requesting service 214 and utilize further services or resources provided by the available service providers to provide the requesting service 214 to the renter 220. By way of example, when providing the request service 214, the service provider 210 may request and utilize the service 234 from the other service providers 230.

The proposed solution enables efficient and secure management of multi-service and multi-tenant systems. In the proposed solution, the leaser information, which may be a business secret for each domain, is screened and protected from the operational and resource layers, since the leaser information is not visible in the service or service profile or any sub-level/layer service or resource profile associated with the leaser's service. Therefore, it is not possible to leak the tenant information to other domains.

Furthermore, the proposed solution also supports the separation of responsibilities and concerns for each domain and each functional block and allows importing leaser profiles from other domains, such as a dedicated security domain of a Service Provider (SP) or a federated domain of a SP federation. When used by an operator, the proposed solution can be easily integrated with existing BSS/customer service systems, such as accounting systems, authentication, authorization and auditing systems (AAA), etc. The proposed solution may further have a unique approach to managing and orchestrating services and resources without regard to multi-tenants and allow tenants to use private resources in the service provider/producer's execution scenario/environment.

The concepts of the present disclosure have been described with reference to fig. 2 and 3. To better understand the solution for multi-tenant management, a detailed example is now given in connection with fig. 4 and 5. Fig. 4 illustrates an example architecture 400 according to some example embodiments of the present disclosure. In the examples described with reference to fig. 4 and 5, the network slice is given as an example of a service for illustration purposes only and without any limitation, and the proposed solution is also applicable to any other type of service. It should be noted that the following described scenarios are for illustrative purposes only and are not intended to be limiting in any way.

First, a brief introduction will now be made to network slicing and related aspects. The idea behind network slicing is to replace a single physical network with multiple logical networks running on a shared infrastructure. These virtual networks are hereinafter referred to as network slices. Each service or tenant may then be provided with its own network slice, i.e. its own dedicated logical network instance, to meet the specific needs of the tenant service.

A network slice is defined as a logical network that provides certain network capabilities and network characteristics. A network slice instance is defined as a set of network function instances and the required resources (e.g., computing, storage, and network resources) to form a deployed network slice.

The single network slice selection assistance information (S-NSSAI) identifies a network slice, and the S-NSSAI includes: slice/service type (SST), which refers to the expected network slice behavior in terms of features and services; and a Slice Discriminator (SD) which is optional information that supplements a slice/service type to discriminate a plurality of network slices of the same slice/service type.

The network slices may be different for supported feature and network function optimizations, in which case such network slices may have different S-NSSAIs, for example, with different slices/service types. An operator may deploy multiple network slices that provide exactly the same features but are used for different groups of UEs, e.g., because they provide different commitment services and/or because they are dedicated to customers, in which case such network slices may have, e.g., different S-NSSAIs with the same SST but different SDs.

In view of the above, a particular service or a particular service of a particular renter may be served by a network slice identified by an S-NSSAI (or NSSAI). A single or multiple network slice instances may support multiple services or network slices.

However, if the renter ID is contained in the S-NSSAI, or even in the service profile used to derive the lower level requirements, there is a risk of divulging the trade secret to other administrative domains (e.g., other operators or service/resource providers). Therefore, there is a need to introduce a mechanism that associates a tenant ID with an S-NSSAI, but at the same time protects the business related tenant ID from daily resource operations. Thus, the proposed rental tube understanding solution can be employed.

The example architecture 400 includes a Network Slice Consumer (NSC)420, a Network Slice Provider (NSP)410, a Network Function Virtualization Provider (NFVP)430, and a Transport Network Provider (TNP) 440. Vertical renter NSC420 may be viewed as a specific example of renter 220 shown in fig. 2. NSP410 may be considered a specific example of service provider 210 shown in fig. 2. Further, each of NFVP 430 and TNP 440 serves as one specific example of service provider 230 shown in fig. 2.

NSP410 may be provided by an operator as an Operation Support System (OSS) and vertical leaser NSC420 has signed a contract with the operator with a negotiated SLA. A leaser object created in the operator's BSS has agreed upon service requirements and associated policies including security policies.

A Network Slice Management Function (NSMF)417, a Network Slice Subnet Management Function (NSSMF)418, and a Network Function Management Function (NFMF)419 are deployed in the domain of NSP 410.

In the example architecture 400, each of the mapping tables 411, 431, and 441 is implemented as a separate managed object. This is for purposes of illustration only and not limitation. In some example embodiments, all or some of mapping tables 411, 431, and 441 may be part of a tenant object.

There may be zero, one, or multiple tenant matrix objects in the domain of NSP 410. For example, all tenants and/or NSMFs share a single tenant matrix object, each tenant has its own tenant matrix object, or each NSMF is associated with a single tenant matrix object, etc. In the example architecture 400, tables 450, 460, and 470 are examples for mapping tables 411, 431, and 441, respectively.

Taking table 450 as an example, the "(vertical) tenant ID" is an example of a tenant identity as described above with reference to fig. 2 and 3, and the "nssai" is an example of an identity for requesting a service as described above with reference to fig. 2 and 3. Here the request service is a network slice. The "NSI ID" column is an optional column of mapping table 411, but may be necessary in the case of network slices.

Assume that NSC420 requests service from NSP410 for the first time. NSC420 (manually, automatically, or semi-automatically) notifies the operator of the network slice allocation request planned on NSP 410. The operator imports the leaser profile 412 for NSC420 from the BSS to NSP410, deploys a leaser anchor 415 for the leaser, and associates the leaser anchor 415 with the leaser profile 412.

As described above, leaser anchor 415 is a function block in the domain of NSP410 for accessing resources from the leaser domain of NSC 420. It may be provided by NSP410 or by NSC420 as a proxy running in the execution environment of NSP 410. Similarly, leaseholder anchors 435 and 445 are associated with

leaseholder profiles

432 and 442, respectively.

Referring now to fig. 5, a flowchart illustrating an example process 500 for leaser management is shown, according to some example embodiments of the present disclosure. For discussion purposes, the process 500 will be described with reference to fig. 4. Process 500 may be considered an example of process 300.

NSC420, which is a vertical tenant, sends 502 a service request to NSP410 to allocate network slices to support evolved mobile broadband (eMBB) services of NSC 420. Upon receiving the service request, the NSMF417 may generate 504 a service profile 413 for the network slice/service based on the service requirements. Alternatively, the service profile 413 may already be included in the service request. NSMF417 may then associate the nssai or another suitable identification for identifying the network slice/service with service profile 413. The nssai is specified by the operator according to slice/service/type and other distinguishing characteristics (e.g., different UE groups, different customers/leasers, and other specific attributes, etc.).

If the TMO is not shared, NSMF417 generates 506 a Tenant Matrix Object (TMO) and creates and inserts a mapping record in the TMO to map, for example, the example table 450 between the tenant ID and the sNSSAI. Note that one leaseid may be associated with zero, one, or multiple snnsais, but one snnsai can only be mapped to one leaseid.

NSP410 then determines 508 a service profile 413. For example, NSMF417 extracts the leaser profile 412 based on the leaser ID, parses the policies or other information of the leaser profile 412, and translates the policies or other information of the leaser profile 412 into the attributes/service requirements of the previously generated service profile 413. This action may include updating the attributes/requirements of the service profile 413 or adding new attributes/requirements to the service profile 413.

The NSMF deploys 510 new network slice instances for the required network slices/services or allocates existing network slice instances for the services according to the attributes/requirements in the service profile 413. Although it is assumed in the example embodiments described herein that a new network slice instance is to be deployed for the service, other scenarios are possible.

If a leaser specific resource is required to support the services of NSC420 according to the service request, then NSMF417 may locate leaser anchor 415 based on information in leaser profile 412, extract access information for accessing the leaser specific resource from leaser profile 412, and extract the leaser specific resource from NSC420 and associate it with service profile 413, e.g., represented as an access point or endpoint for the resource, and access information required to access the resource, such as a public credential (e.g., root certificate) -.

NSP410 then provides the requested service to NSC 420. For example, the NSMF417 decomposes 512 the requirements/attributes of the service profile 413 into more specific attributes of the lower level service profile 416, which may be a slice profile in this example. The corresponding nssai may be transferred to a lower level service profile 416, if desired.

The NSMF417 may invoke a management service (MnS) provided by the NSSMF 418 to allocate a Network Slice Subnet (NSS) to construct a network slice instance to support the service.

NSSMF 418 may interpret the attributes in lower level service profile 416 and determine to create a dedicated NSS instance (NSSI) for service 414 or to update an existing NSSI to support service 414. NSSMF 418 may then translate the attributes to configuration parameters for a Network Function (NF) if the NSS needs to form a child NSS and/or attributes to other lower level service profiles 416 and/or attributes to a network service descriptor if virtualized resources are needed to build the NSS instance. The nssai may be transferred to the NF's configuration parameters and/or other lower level service profile 416, if desired.

NSSMF 418 calls mns(s) provided by NFMF 419 and/or other NSSMFs and/or other mnfs to deploy or configure the relevant resources based on the attributes in lower-level service profile 416.

In some example embodiments, virtualized resources are supported to deploy NSS instances. A leaser profile 432 for NSP410 is generated or imported in NFVP 430, which may provide virtualized resources for NSP 410. A leaseholder anchor 435 provided by NSP410 or NFVP 430 is deployed in NFVP 430 to proxy messages between NFVP 430 and NSP 410. If NSP410 does not have a TMO, a tenant matrix object, such as mapping table 431, is created in NFVP 430.

NSSMF 418, which manages the NSS instance in NSP410, calls 514 a Function Block (FB) of NFVP 430 (e.g., an NFV orchestrator) to deploy the network service. The FB of NFVP 430 may extract 516 the leaser ID for NSP410 from the request, create a Network Service (NS) instance from the request and generate a record in mapping table 431 to map the leaser ID for NSP410 to the NS ID, and respond 518 to NSSMF 418.

After successful deployment and configuration of resources, NSSMF 418 sends a response or notification to NSMF 417. NSMF417 accordingly creates 520 a network slice instance and sends 522 the nssai of the network slice/service to NSC 420. In an example embodiment, the NSMF417 may return the network slice instance ID as a service traffic model to the NSCs 420 in the network slice.

Although not depicted, NSP410 may also request and utilize services/resources from TNP 440.

In scenario 1 above, the vertical tenant NSC420 requests the NSP410 to allocate a network slice for the eMBB service. More scenarios are described below. In scenario 2 of network slice/de-allocation of services, assume that a network slice for an eMBB service has been allocated to a vertical tenant NSC420 and a Tenant Matrix Object (TMO) such as a mapping table 411 has been created for NSC420, and the mapping between tenant ID and service ID is already in mapping table 411.

After receiving a request to deallocate a network slice/service from the vertical leaser's NSC420, the NSMF417 of NSP410 terminates the resource referenced by the service's nssai. NSMF417 may terminate the entire network slice instance that serves the network slice/service identified by the nssai, or update the network slice instance to terminate only resources associated with the nssai.

To terminate or update a network slice instance, NSMF417 may invoke the associated NSSMF 418 to deallocate resources associated with the nssai. NSSMF 418 may terminate the entire NSSI or update the NSSI accordingly.

To terminate or update NSSI, NSSMF 418 may call NFMF 419 and/or other NSSMFs and/or mnfs in other domains to terminate the relevant resources. In an example embodiment, NSSMF 418 may invoke NFMF 419 to remove the nssai from the nssai list attribute of a Managed Function (Managed Function). In another example embodiment, NSSMF 418 may invoke, for example, a NFV orchestrator to terminate a network service instance or virtualized network function instance associated with the nssai.

After successful deallocation of the network slice/service, NSMF417 removes the associated record of the mapping between the tenant ID and the nssai of NSC420 from mapping table 411. NSMF417 then sends a response to NSC 420.

In scenario 3, where the tenant profile is updated, it is assumed that multiple network slices for eMBB, ultra-reliable low latency communication (urlcc), or large-scale internet of things (mIOT) services have been allocated to a vertical tenant, such as NSC 420. Assume also that a TMO has been created for the tenant, and that a mapping between the tenant ID and service ID for NSC420 has been created in the TMO.

As the policy of NSC420 changes (e.g., the organizational policy of NSC420 changes, the rules of the industry to which NSC420 belongs, etc.), NSC420 triggers updates to the leaser object and the leaser profile 412 in NSP410 or other BSS or OSS of the operator.

NSMF417 of NSP410 may update leaseholder profile 412 accordingly. Further, NSMF417 may extract all the nssais associated with the tenant ID and update the service profile identified by the nssai, and finally modify the relevant network slice/service according to the update attributes/requirements of the service profile. The NSMF417 may then notify the NSC420 about the change in network slices/services.

In scenario 4, where the leaser profile is removed, it is assumed that all network slices/services have been deallocated from NSP410 and the leaser or NSP410 has decided to terminate the contract between them.

The renter or operator triggers the deletion of the renter object and the renter profile from NSP410 and other operator systems. NSMF417 terminates the leaser anchor 415 from NSP 410. In the case where mapping table 411 is specific to a leaser, NSMF417 may remove the entire mapping table 411 from NSP 410. In the case where mapping table 411 contains an entry or record for another leaser, NSMF417 may remove only the entry corresponding to that leaser.

It should be understood that the actions described with respect to a function in NSP410 may be implemented by another function. For example, in the scenario described above, all leaser related actions are described as being completed by the NSMF 417. In other example embodiments, those actions related to the leaser, such as creating, removing, updating the TMO, deploying, terminating the TA, retrieving and interpreting the leaser ID and leaser policy, etc., may be performed by another MF in NSP 410.

Further details of example embodiments according to the present disclosure will be described with reference to fig. 6 to 7.

Fig. 6 shows a flowchart of an example method 600 according to some example embodiments of the present disclosure. Method 600 may be implemented on any suitable device. For example, method 600 may be implemented at a first apparatus associated with service provider 210 as shown in FIG. 2. For discussion purposes, the method 600 will be described with reference to fig. 2.

At block 610, the first device generates a mapping between the leaser and the requested service based on the determination of the service requested by the leaser. At block 620, the first device determines a service profile for the requested service based on the mapping and a leaser profile for the leaser, the leaser profile including information for supporting the service for the leaser, the service profile including service requirements for the requested service. At block 630, the first device provides the requested service to a second device associated with the leaser based at least in part on the service profile.

In some example embodiments, generating the mapping comprises: determining a first identification for the leaser and a second identification for requesting the service; and adding a first entry to a mapping table maintained at the first device, the first entry mapping the first identity to the second identity.

In some example embodiments, the mapping table is a separate object or part of an object corresponding to the renter.

In some example embodiments, the mapping table further includes a second entry mapping the first identification to a third identification for further services requested by the leaser.

In some example embodiments, the mapping table further includes a third entry mapping a fourth identification for the other leaser to a fifth identification of the other service requested by the other leaser.

In some example embodiments, the method 600 further comprises: determining, based on the renter profile, available resources of the renter for the first device to provide the requested service; and accessing the available resources through a function configured for communication between the first device and a second device associated with the leaser.

In some example embodiments, the method 600 further comprises: obtaining a service profile based on the mapping according to the change in the tenant profile; and update the service profile based on changes to the leaser profile.

In some example embodiments, the method 600 further comprises: removing the mapping between the leaser and the requested service in response to at least one of: the removal of a leaser profile, or the removal of a service profile.

In some example embodiments, providing the request service comprises: determining available service providers for the first device; and utilize further services or resources provided by the available service providers.

In some example embodiments, the method 600 further comprises: generating a leaser profile based on information for supporting a service for the leaser; or receive a leaser profile generated by another device different from the first device.

In some example embodiments, the first apparatus is an apparatus at a service provider and the second apparatus is an apparatus at a leaser.

Fig. 7 shows a flowchart of an example method 700 according to some example embodiments of the present disclosure. Method 700 may be implemented on any suitable device. For example, as shown in fig. 2, the method 700 may be implemented at a second device in the leasing party 220. For purposes of discussion, the method 700 will be described with reference to fig. 2.

At block 710, the second device sends a lease request for a service to the first device. At block 720, the second device receives the requested service from the first device, provides the requested service based at least in part on a service profile for the requested service, the service profile including service requirements for the requested service, the service profile determined based on a mapping between the renter and the requested service and a renter profile for the renter, the renter profile including information for supporting services for the renter.

In some example embodiments, an apparatus capable of performing the method 600 may comprise means for performing the various steps of the method 600. The apparatus may be embodied in any suitable form. For example, the apparatus may be implemented in a circuit or a software module.

In some example embodiments, the apparatus comprises: means for generating, at the first device, a mapping between the leaser and the requested service based on the determination of the service requested by the leaser; means for determining a service profile for the requested service based on the mapping and a leaser profile for the leaser, the leaser profile including information for supporting the service for the leaser, the service profile including service requirements for the requested service; and means for providing the requested service to a second apparatus associated with the leaser based at least in part on the service profile.

In some example embodiments, the means for generating a mapping comprises: means for determining a first identity for the leaser and a second identity for the requesting service; and means for adding a first entry mapping the first identity to the second identity to a mapping table maintained at the first device.

In some example embodiments, the mapping table further includes a second entry mapping the first identification to a third identification for a further service requested by the leaser.

In some example embodiments, the apparatus further comprises: means for determining available resources of the leaser for the first device to provide the requested service based on the leaser profile; and means for accessing the available resources through a function configured for communication between the first apparatus and a second apparatus associated with the leaser.

In some example embodiments, the apparatus further comprises: means for obtaining a service profile based on the mapping according to the change in the tenant profile; and means for updating the service profile based on the change in the tenant profile.

In some example embodiments, the apparatus further comprises: means for removing a mapping between a leaser and a requested service in response to at least one of: the removal of a leaser profile, or the removal of a service profile.

In some example embodiments, an apparatus for providing request services includes: means for determining available service providers for the first device; and means for utilizing further services or resources provided by the available service providers.

In some example embodiments, the apparatus further comprises: means for generating a leaser profile based on information for supporting a service of the leaser; or means for receiving a leaser profile generated by another device different from the first device.

In some example embodiments, a device capable of performing method 700 may include means for performing the various steps of method 700. The apparatus may be embodied in any suitable form. For example, the apparatus may be implemented in a circuit or a software module.

In some example embodiments, the apparatus comprises: means for sending a lease request for a service to a first device and at a second device; and means for receiving the requested service from the first device, providing the requested service based at least in part on a service profile of the requested service, the service profile including service requirements for the requested service, the service profile determined based on a mapping between the renter and the requested service and a renter profile for the renter, the renter profile including information for supporting services for the renter.

Fig. 8 is a simplified block diagram of an apparatus 800 suitable for implementing embodiments of the present disclosure. An apparatus 800, such as a first apparatus associated with a service provider or a second apparatus associated with a leaser, may be provided to implement a communication device. As shown, the apparatus 800 includes one or more processors 810, one or more memories 820 coupled to the processors 810, and one or more communication modules 840 coupled to the processors 810.

The communication module 840 is used for bidirectional communication. The communication module 840 has at least one antenna to facilitate communication. A communication interface may represent any interface necessary to communicate with other network elements.

As a non-limiting example, the processor 810 may be of any type suitable for a local technology network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, Digital Signal Processors (DSPs) and processors based on a multi-core processor architecture. The device 1200 may have multiple processors, such as an application specific integrated circuit chip that is time dependent from a clock synchronized to the main processor.

The memory 820 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memory include, but are not limited to, Read Only Memory (ROM)824, Electrically Programmable Read Only Memory (EPROM), flash memory, a hard disk, a Compact Disk (CD), a Digital Video Disk (DVD), and other magnetic and/or optical storage. Examples of volatile memory include, but are not limited to, Random Access Memory (RAM)822 and other volatile memory that does not persist during a power failure.

The computer programs 830 include computer-executable instructions that are executed by the associated processor 810. The program 830 may be stored in the ROM 820. Processor 810 may perform any suitable acts and processes by loading programs 830 into RAM 820.

Embodiments of the disclosure may be implemented by the program 830 such that the apparatus 800 may perform any of the processes of the disclosure as discussed with reference to fig. 6-7. Embodiments of the present disclosure may also be implemented in hardware or a combination of hardware and software.

In some embodiments, program 930 can be tangibly embodied in a computer-readable medium, which can be included in device 900 (e.g., in memory 920) or other storage device accessible to device 900. The device 900 may load the program 930 from the computer-readable medium into RAM 922 for execution. The computer readable medium may include any type of tangible, non-volatile storage device, such as a ROM, EPROM, flash memory, hard disk, CD, DVD, etc. Fig. 9 shows an example of a computer readable medium 900 in the form of a CD or DVD. The computer readable medium has program 830 stored thereon.

In general, the various embodiments of the disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While various aspects of the embodiments of the disclosure are illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that the block diagrams, apparatus, systems, techniques or methods described herein may be implemented in a manner that: non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing device, or some combination thereof.

The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product comprises computer executable instructions, such as instructions contained in program modules, that are executed in a device on a target real or virtual processor to perform the

methods

600 or 700 described above with reference to fig. 6 and 7. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. In various embodiments, the functionality of the program modules may be combined or split between program modules as desired. Machine-executable instructions for program modules may be executed within local or distributed devices. In a distributed fashion, program modules may be located in both local and remote memory storage media.

Program code for performing the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowchart and/or block diagram to be implemented. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of the present disclosure, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus or processor to perform various processes and operations as described above. Examples of a carrier include a signal, computer readable medium, and the like.

The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a computer-readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Further, while operations are described in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous. Also, while the above discussion contains several specific implementation details, these should not be construed as limitations on the scope of the disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.

Although the disclosure has been described in language specific to structural features and/or methodological acts, it is to be understood that the disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A first device comprising:

at least one processor; and

at least one memory including computer program code;

the at least one memory and the computer program code configured to, with the at least one processor, cause the first apparatus at least to:

generating a mapping between a leaser and a requested service according to a determination that the leaser requests the service;

determining a service profile for the requested service based on the mapping and a leaser profile for the leaser, the leaser profile including information for supporting the service for the leaser, the service profile including service requirements for the requested service; and

providing the requested service to a second device associated with the leaser based, at least in part, on the service profile.

2. The first apparatus of claim 1, wherein the first apparatus is caused to generate the mapping by:

determining a first identity for the leaser and a second identity for the requesting service; and

adding a first entry mapping the first identity to the second identity in a mapping table maintained by the first device.

3. The first apparatus of claim 2, wherein the mapping table is a separate object or part of an object corresponding to the renter.

4. The first apparatus of claim 2, wherein the mapping table further comprises a second entry mapping the first identification to a third identification for another service requested by the leaser.

5. The first apparatus of claim 2, wherein the mapping table further comprises a third entry mapping a fourth identification for another leaser to a fifth identification of another service requested by the other leaser.

6. The first apparatus of claim 1, wherein the first apparatus is further caused to:

determining available resources of the leaser for the first device to provide the requested service based on the leaser profile; and

accessing the available resources through a function configured for communication between the first device and the second device associated with the leaser.

7. The first apparatus of claim 1, wherein the first apparatus is further caused to:

obtaining the service profile based on the mapping according to changes in the tenant profile; and

updating the service profile based on changes in the tenant profile.

8. The first apparatus of claim 1, wherein the first apparatus is further caused to:

removing the mapping between the leaser and the requesting service in response to at least one of:

remove the renter profile, or

Removing the service profile.

9. The first device of claim 1, wherein the first device is caused to provide the requested service by:

determining available service providers for the first device; and

utilizing another service or resource provided by the available service provider.

10. The first apparatus of claim 1, wherein the first apparatus is further caused to:

generating the leaser profile based on the information for supporting the service for the leaser; or

Receiving the leaser profile generated by another device different from the first device.

11. The first device of claim 1, wherein the first device is a device at a service provider and the second device is a device at the leaser.

12. A second apparatus, comprising:

at least one processor; and

at least one memory including computer program code;

the at least one memory and the computer program code configured to, with the at least one processor, cause the second apparatus at least to:

sending a lease request for a service to a first device; and

receiving the request service from the first device, providing the request service based at least in part on a service profile of the request service, the service profile including service requirements for the request service, the service profile determined based on a mapping between the leaser and the request service and a leaser profile for the leaser, the leaser profile including information for supporting services for the leaser.

13. The second device of claim 12, wherein the first device is a device at a service provider and the second device is a device at the leaser.

14. A method, comprising:

generating, at a first device, a mapping between a leaser and a requested service, based on a determination of the service requested by the leaser;

providing a request service to a second device associated with the leaser based, at least in part, on the service profile.

15. The method of claim 14, wherein generating the mapping comprises:

16. The method of claim 15, wherein the mapping table is a separate object or part of an object corresponding to the renter.

17. The method of claim 15, wherein the mapping table further comprises a second entry mapping the first identity to a third identity for further services requested by the leaser.

18. The method of claim 15, wherein the mapping table further comprises a third entry mapping a fourth identification for another leaser to a fifth identification for another service requested by the other leaser.

19. The method of claim 14, further comprising:

20. The method of claim 14, further comprising:

obtaining the service configuration file based on the mapping according to the change of the leaser configuration file; and

updating the service profile based on a change in the tenant profile.

21. The method of claim 14, further comprising:

removing the renter profile, or

Removing the service profile.

22. The method of claim 14, wherein providing the request service comprises:

determining available service providers for the first apparatus; and

23. The method of claim 14, further comprising:

generating the leaser profile based on information supporting the service for the leaser; or

A tenant profile generated by another device different from the first device is received.

24. The method of claim 14, wherein the first device is a device at a service provider and the second device is a device at the renter.

25. A method, comprising:

sending a lease request for a service to a first device and at a second device; and

26. The method of claim 25, wherein the first device is a device at a service provider and the second device is a device at the renter.

27. An apparatus, comprising:

means for generating, at a first device, a mapping between a leaser and a requested service based on a determination of the service requested by the leaser;

means for determining a service profile for the requested service based on the mapping and a leaser profile for the leaser, the leaser profile including information for supporting a service for the leaser, the service profile including service requirements for the requested service; and

means for providing the requested service to a second device associated with the leaser based at least in part on the service profile.

28. An apparatus, comprising:

means for sending a lease request for a service to a first device and at a second device; and

means for receiving the requested service from the first device, the requested service being provided based at least in part on a service profile of the requested service, the service profile comprising service requirements for the requested service, the service profile being determined based on a mapping between the renter and the requested service and a renter profile for the renter, the renter profile comprising information for supporting services for the renter.

29. A non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the method of any of claims 14-24.

30. A non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the method of any of claims 25-26.