Lessee Management

Abstract

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

Description

Technical Field

[0001] The embodiments of the present disclosure generally relate to the field of telecommunications, and in particular, to methods, devices, apparatuses, and computer-readable storage media for tenant management. Background Art

[0002] Mobile networks are becoming increasingly important for the continued digitization of business and everyday life and the transition to a connected society. In addition, the fifth-generation (5G) network is expected to provide unique opportunities for operators to solve and provide new business models for consumers, enterprises, vertical industries, and third-party partners. A large number of different customer types, each requiring a specific communication solution, are inherently difficult to handle due to the need to address a wide range of different requirements at any point in time during deployment.

[0003] Dedicated physical networks would be an obvious solution as they can be perfectly customized and adapted to service- or business-specific requirements and provide maximum performance. However, in many cases, the resources of such networks are underutilized most of the time and over large geographical areas. Therefore, a common infrastructure platform that can be shared among multiple enterprises is needed. For this purpose, the 5G New Radio Multi-Service Adaptive Network Architecture (NORMA) has proposed a multi-service multi-tenant system architecture based on network slicing. Summary of the Invention

[0004] Generally, the example embodiments of the present disclosure provide solutions for tenant management across multiple domains and multiple layers.

[0005] In a first aspect, a first apparatus is provided. The first apparatus includes: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code are configured to, by using the at least one processor, cause the first apparatus to generate a mapping between a tenant and a requested service according to the determination of the service requested by the tenant; determine a service profile of the requested service based on the mapping and a tenant profile for the tenant, the tenant profile including information for supporting the service for the tenant, and the service profile including service requirements for the requested service; and provide the requested service to a second apparatus associated with the tenant at least partially based on the service profile.

[0006] In a second aspect, a second apparatus is provided. The second apparatus comprises: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code are configured to, using the at least one processor, cause the second apparatus to send a request for a service by a lessee to a first apparatus; and receive the requested service from the first apparatus and provide the requested service at least partially based on a service profile of the requested service, the service profile including service requirements for the requested service, the service profile being determined based on a mapping between the lessee and the requested service for the lessee and a lessee profile of the lessee, the lessee profile including information for supporting the service for the lessee.

[0007] In a third aspect, a method is provided. The method comprises: generating, at a first apparatus, a mapping between a lessee and a requested service according to the determination of the service requested by the lessee; determining a service profile of the requested service based on the mapping and a lessee profile of the lessee, the lessee profile including information for supporting the service for the lessee, the service profile including service requirements for the requested service; and providing the requested service to a second apparatus associated with the lessee at least partially based on the service profile.

[0008] In a fourth aspect, a method is provided. The method comprises: sending, to a first apparatus and at a second apparatus, a request for a service by a lessee; and receiving the requested service from the first apparatus, the requested service being provided at least partially based on a service profile of the requested service, the service profile including service requirements for the requested service, the service profile being determined based on a mapping between the lessee and the requested service and a lessee profile of the lessee, the lessee profile including information for supporting the service for the lessee.

[0009] In a fifth aspect, an apparatus is provided, comprising: means for generating, at a first apparatus, a mapping between a lessee and a requested service according to the service requested by the lessee; means for determining a service profile of the requested service based on the mapping and a lessee profile of the lessee, the lessee profile including information for supporting the service for the lessee, the service profile including service requirements for the requested service; and means for providing the requested service to a second apparatus associated with the lessee at least partially based on the service profile.

[0010] In a sixth aspect, there is provided a device, comprising: means for sending a lessee's request for a service to a first device and at a second device; and means for receiving a service request from the first device, the service request being provided at least in part based on a service profile for the requested service, the service profile including service requirements for the requested service, the service profile being determined based on a mapping between the lessee and the requested service and a lessee profile for the lessee, the lessee profile including information for supporting the service for the lessee.

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

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

[0013] It should be understood that the summary section is not intended to identify key or essential features of the embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become readily apparent through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0015] Figure 1 A schematic diagram illustrating an example architecture for a multi-lessee and multi-service 5G system is shown;

[0016] Figure 2 An example environment in which embodiments of the present disclosure can be implemented is shown;

[0017] Figure 3 A flowchart illustrating an example process for lessee management is shown;

[0018] Figure 4 An example architecture according to some example embodiments of the present disclosure is shown;

[0019] Figure 5 A flowchart illustrating an example process for lessee management according to some example embodiments of the present disclosure is shown;

[0020] Figure 6 A flowchart illustrating an example method according to some example embodiments of the present disclosure is shown;

[0021] Figure 7 A flowchart illustrating an example method according to some example embodiments of the present disclosure is shown;

[0022] Figure 8A simplified block diagram of an apparatus suitable for implementing embodiments of the present disclosure is shown; and

[0023] Figure 9 A block diagram of an example computer-readable medium according to some embodiments of the present disclosure is shown.

[0024] Throughout the drawings, the same or similar reference numerals denote the same or similar elements. Detailed embodiments

[0025] Now, the principles of the present disclosure will be described with reference to some example embodiments. It should be understood that the description of these embodiments is only for the purpose of illustration and to assist those skilled in the art in understanding and implementing the present invention, and does not mean any limitation to the scope of the present disclosure. The disclosure described herein can be implemented in various ways other than the ways described below.

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

[0027] References in the present disclosure to "one embodiment", "an embodiment", "example embodiment", etc. mean that the described embodiment may include a particular feature, structure, or characteristic, but not necessarily every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is considered within the knowledge of those skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments, whether or not explicitly described.

[0028] It should be understood that although the terms "first" and "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, without departing from the scope of the example embodiments, the first element may be referred to as the second element, and similarly, the second element may be referred to as the first element. As used herein, the term "and / or" includes any and all combinations of one or more of the listed terms.

[0029] The terms used herein are for the purpose of describing particular embodiments only and are not intended to limit the 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 when used herein, the terms "comprises", "comprising", "has", "having", "includes", and / or "including" specify the presence of the stated features, elements, and / or components, etc., but do not preclude the presence or addition of one or more other features, elements, components, and / or combinations thereof.

[0030] As used in this application, the term "circuit" may refer to one or more or all of the following:

[0031] (a) A pure hardware circuit implementation (such as an implementation in only analog and / or digital circuits) and

[0032] (b) A combination of hardware circuits and, for example (where applicable), software:

[0033] (i) A combination of analog and / or digital hardware circuits and software / firmware, and

[0034] (ii) Any part of a hardware processor and 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

[0035] (c) A hardware circuit and / or processor, such as a microprocessor or a part of a microprocessor, that requires software (e.g., firmware) to operate, but the software may not be present when not needed for operation.

[0036] The definition of the circuit applies to all uses of the term in this application, including all uses in any claim. As another example, as used in this application, the term "circuit" also encompasses an implementation of only a hardware circuit or a processor (or processors) or a part of a hardware circuit or a processor and its (or their) accompanying software and / or firmware. For example, if applicable to a particular claim element, the term "circuit" also encompasses a baseband integrated circuit or a processor integrated circuit similar to those used in mobile devices or servers, cellular network devices, or other computing or network devices.

[0037] As used herein, the term "communication network" refers to a network that follows 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), etc. In addition, the communication between a terminal device and a network device in a communication network may be carried out according to any suitable generation of communication protocols, which include but are not limited to the 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 known currently or developed in the future. Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development of communication, there will of course also be future types of communication technologies and systems that can embody the present disclosure. It should not be considered as limiting the scope of the present disclosure to the above systems.

[0038] As used herein, the term "service provider" may be considered an entity that produces services to be accessed by service consumers. For example, the service provider may be referred to as the Authentication Server Function (AUSF) defined in the 5G core network function, which produces authentication services for terminal devices (e.g., User Equipment (UE)) for access and mobility management functions (AMF) to access. The terms "service provider" and "service producer" may be used interchangeably herein.

[0039] As described above, a system architecture with multi-service and multi-tenant capabilities based on network slicing has been proposed. Figure 1 Figure 100 is illustrated, which shows an example architecture for a multi-tenant and multi-service 5G system. In Figure 1 this example, the exemplary 5G system 110 can be divided into three levels, namely the telecommunications service level 120, the logical network level 130, and the infrastructure level 140. The infrastructure level 140 may include 5G infrastructure 141, such as various physical devices and software deployed thereon. The virtual networks 131 - 133 at the logical network level 130 can provide network slices to support various services 121 - 124 at the telecommunications service level 120. Various entities can 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.

[0040] As Figure 1 shown in this example, in 5G systems and possibly any other communication systems, it allows vertical industries to develop and participate in business models and the digital economy quickly while saving costs. It not only has ultra-reliable, low-latency, extremely flexible, and dynamically adoptable network traffic on demand, but also significantly increases complexity due to the characteristics of multi-tenancy, multi-network slicing, multi-domain, multi-layer, and resource sharing. Therefore, in this complex ecosystem, it is difficult to guarantee and protect the resources of tenants.

[0041] In addition, flexible 5G systems allow tenants to integrate their own services, functions, networks, or resources with those of the producer / provider to build end-to-end services. In this way, tenants can utilize existing resources and expertise, and then reduce costs and improve efficiency. However, on the other hand, it increases the complexity of the 5G system and creates a threat surface on the system.

[0042] The European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) group has introduced resourceGroupId to represent tenants that allow the NFV management and orchestration system to create and separate virtualized resources for multi-tenancy, but only within a single virtualization domain. Many cloud and service providers support multi-tenancy, but also within a single domain and single layer.

[0043] In the Fifth Service and System Aspects (SA5) Working Group of the 3rd Generation Partnership Project (3GPP), a Study Item (SI) was created to study the tenancy aspects in 5G networks and network slices, and the Study Item (SI) was recently approved as a normative specification. However, the SI and WI only address the tenant identification and access management data for each tenant in the 3GPP management domain. The tenant isolation problem across multiple layers and multiple domains is not addressed. In particular, the SI / WI is proposed to include tenant identification or information as part of a network slice object or service profile. This approach may expose tenant information to the resource layer and, worse, leak tenant information to other domains.

[0044] The 5G Security Working Group of the Fraud and Security Architecture Group (FSAG) of the Global System for Mobile Communications Association (GSMA) has also presented a problem statement on the security aspects of multi-tenancy in 5G networks and network slices, but no solution has been proposed yet.

[0045] The performance and security guarantee of a multi-tenant 5G system are necessary conditions for the large-scale commercial use of 5G networks. Therefore, it is necessary to manage tenants to ensure the performance and security of the multi-tenant system.

[0046] According to an embodiment of the present disclosure, a solution for tenant management is proposed. In the present disclosure, the mapping between a tenant and the service requested by the tenant is maintained by the corresponding service provider. In this way, the tenant profile of the tenant and the service profile of the requested service are correlated with each other via this mapping. The service provider can provide the requested service according to the service profile determined based on this mapping and the tenant profile. The mapping can be implemented as an entry in a mapping table or a tenant matrix. Multiple tenants and / or multiple services can be managed efficiently and securely.

[0047] Embodiments of the present disclosure can be used to manage multiple tenants and their resources across multiple layers and multiple domains, and allow protecting tenants and their resources in a multi-domain and multi-layer framework. In addition, the solution also allows the tenant function running in the provider / producer scenario to securely access the private resources of the tenant on demand.

[0048] The following is combined with Figures 2 - 5 The principles and implementation manners of the present invention are described in detail. Figure 2 An example environment 200 in which embodiments of the present disclosure can be implemented is illustrated. The environment 200 includes a service provider 210, which can provide a service 214 for a tenant 220. The service provider 210 can maintain a service profile 213 for the service 214 requested by the tenant 220 and a tenant profile 212 for the tenant 220. The service provider 210 can be within a management domain (e.g., management domain A).

[0049] To manage the lessee 220 and potential other lessees (not shown), the service provider 210 maintains a mapping table 211, which may also be referred to herein as a lessee matrix (TM). The mapping table 211 can map the lessees of the service provider 210 to the services requested by the corresponding lessees, and vice versa. For example, the mapping table 211 includes an entry or record that maps the lessee 220 to the requested service 214. It can be understood that a lessee may have multiple services, but one service can only serve one lessee. Therefore, using the mapping table 210, a lessee (e.g., lessee 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 lessee.

[0050] The mapping table 211 can map the lessee 220 to the service 214 by mapping the identifier of the lessee 220 to the identifier of the service 214 or the identifier of the service profile 213. In some example embodiments, the identifier of the lessee 220 may be the lessee identifier (lessee ID) of the lessee 220. In some example embodiments, the identifier of the service 214 may be the service identifier (service ID) of the service 214.

[0051] A service (e.g., service 214) can be implemented using resources that can be shared by multiple services. The services and resources used herein can be at least one of application programs, communication services, network slices, network slice subnets, mobile networks, transport networks, network services, virtual network functions, network functions, and microservices. In addition, the resources can also be virtual machines, containers, hardware, etc.

[0052] The service profile 213 can include service requirements for the service 214, and the service requirements can be used to deploy, configure, monitor, update, and scale the resources of the service 214. The service requirements can include, for example, latency, availability, isolation, coverage, elasticity, security, etc. The service profile is associated with the resources.

[0053] The lessee profile 212 can include various information about the lessee 220, including but not limited to lessee characteristics, lessee access information, lessee policies (e.g., security policies) required to support the services of the lessee 220, and any other appropriate information. As used herein, the object corresponding to a lessee can be referred to as a lessee object. If the lessee object of the lessee 220 is managed in the same management domain (i.e., management domain A), the lessee profile 212 can be associated with the lessee object. Otherwise, the lessee profile 212 that only includes the information that needs to be known can be imported from other management domains.

[0054] In example environment 200, the tenant profile 212 and the service profile 213 are associated with each other via the mapping table 211 rather than directly. Although only the tenant profile 212 and the service profile 213 are shown, the mapping table 211 can be associated with a set of tenant profiles and a set of service profiles. There may be one or more tenant matrices in management domain A. A tenant matrix can be an independent object and can be part of a tenant object if tenant objects are managed in the same management domain.

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

[0056] In some example embodiments, environment 200 may include a tenant anchor 215, which is a function block that brokers messages between service provider 210 and tenant 220 for cases where a service (e.g., service 214) in the management domain of service provider 210 needs to access resources of tenant 220 in the tenant domain. The tenant anchor 215 can be an agent deployed and running in the context / execution environment of the management domain of service provider 210. Through tenant anchor 215, service provider 210 can only access tenant 220, in other words, it accesses the direct tenant, but not the sub-tenants of tenant 220.

[0057] In some example embodiments, service provider 210 or processing / function blocks in management domain A can be a tenant of services / resources provided by another domain, such as service provider 230. In such example embodiments, service provider 210 can be considered a tenant of service provider 230 and requests service 234 from service provider 234.

[0058] Service provider 230 can maintain a mapping table 231, a tenant profile 232 for service provider 210, and a service profile 233 for requested service 234. The mapping table 231, tenant profile 232, and service profile 233 are respectively similar to the mapping table 211, tenant profile 212, and service profile 213. Service provider 230 can be within management domain B. The tenant information of tenant 220 is not known to any entity in management domain B. In some example embodiments, service provider 230 can access resources in management domain A via a tenant anchor 235, similar to tenant anchor 215.

[0059] It should be understood that the lessee and the service provider are relative concepts. A service provider can be a lessee of another service provider. For example, in some example embodiments, service provider 210 can be a lessee of service provider 230. Additionally, a lessee can be a service provider to another lessee. For example, lessee 220 can provide services to another lessee (not shown).

[0060] Now refer to Figure 3 , which shows a flowchart illustrating an example process 300 for lessee management. For the purpose of discussion, process 300 will be described with reference to Figure 2 . Process 300 may involve lessee 220 and service provider 210 as shown in Figure 2 . Although process 300 is described with respect to service provider 210, it should 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 or otherwise associated with service provider 210. Similarly, the actions described with respect to lessee 220 may be performed by a device (which may be referred to as a second device) or functional block implemented at or otherwise associated with lessee 220.

[0061] Lessee 220 (e.g., a device associated with lessee 220) sends 305 a request for service 214 to service provider 210 (e.g., to a device implemented at service provider 210). After determining that lessee 220 requests service 214, service provider 210 generates a mapping 310 between lessee 220 and the requested service 214.

[0062] In some example embodiments, the mapping can be a separate record maintained at service provider 210. In some example embodiments, the mapping can be an entry or record in a lessee matrix, such as mapping table 211. For example, service provider 210 may determine an identifier for lessee 220 (which, for the purpose of discussion, may be referred to as a first identifier) and an identifier for the requested service 214 (which, for the purpose of discussion, may be referred to as a second identifier). Service provider 210 may then add a first entry to mapping table 211 that maps the first identifier to the second identifier.

[0063] The identifier for lessee 220 can be the lessee ID of lessee 220 or any suitable identifier that can distinguish lessee 220 from any other lessee of service provider 210. In some example embodiments, the identifier for the requested service 214, for example, in the case where service 214 has been deployed, can be the service ID of service 214. In some example embodiments, the identifier for the requested service 214 can be the identifier of service profile 213 associated with the requested service 214.

[0064] With the help of the mapping table 211 or the tenant matrix, multiple services and / or multiple tenants can be managed in a centralized manner. In some example embodiments, the mapping table 211 may further include a second entry that maps a first identifier to a third identifier for a further service (not shown) requested by the tenant 220. In some example embodiments, the mapping table 211 may further include a third entry that maps a fourth identifier for another tenant to a fifth identifier for another service requested by the other tenant.

[0065] In some example embodiments, the mapping table 211 can be an independent object, e.g., an independent object in the management domain A of the service provider 210. In this case, the mapping table 211 may include different entries for different tenants of the service provider 210, such as Figure 4 the example table 450 shown below, which will be described in detail hereinafter.

[0066] In some example embodiments, the mapping table 211 can be part of another object. For example, if an object corresponding to the tenant 220 that manages the tenant object also known as the tenant 220 is in the same management domain as the mapping table 211, then the mapping table 211 can be part of the tenant object. In this case, the mapping table 211 can maintain entries for different services for the tenant 220.

[0067] Still referring to Figure 3 , the service provider 210 determines 315 the service profile 213 for the requested service 214 based on the mapping (e.g., the entries in the mapping table 211) and the tenant profile 212 for the tenant 220. The tenant profile 212 includes at least information for supporting the services for the tenant 220, and the service profile 213 includes at least one service requirement for the requested service 214. To determine 315 the service profile 213, as described in detail hereinafter, the service provider 210 may modify or update the service profile 213 that has been generated or otherwise obtained.

[0068] As referred to above with reference to Figure 2 , the tenant profile 212 defines tenant characteristics, tenant access information, tenant policies required to support the services for the tenant 220, and any other information related to the tenant 220. The tenant profile 212 is associated with an identifier for the tenant 220, e.g., associated with the tenant ID of the tenant 220.

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

[0070] As mentioned above Figure 2 the service profile 213 may define service requirements for service 214, and the service requirements may be used to deploy, configure, monitor, update, and scale resources for service 214 when tenant 220 requests service 214. Service requirements may include, for example, latency, availability, isolation, coverage, elasticity, security, etc. Service profile 213 may be generated based on a service request from tenant 220.

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

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

[0073] Service provider 210 provides 320 requested service 214 to a second device associated with tenant 220 at least in part based on service profile 213. For example, a functional block of service provider 210 may manage and orchestrate resources for requested service 214 of tenant 220 according to the attributes / requirements in service profile 213.

[0074] In some example embodiments, the service provider 210 may access or utilize the resources of the tenant 220 through a functional block (e.g., the tenant anchor 215 in Figure 2 ) that proxies messages between the domain of the service provider 210 and the domain of the tenant 220. The tenant anchor 215 may be a proxy (of the tenant 220) deployed and running in the context / execution environment of the domain of the service provider 210 (in this case, administrative domain A). Figure 2 The service provider 210 may determine the available resources of the tenant 220 based on the tenant profile 212 for the service provider 210 (e.g., the first device) to provide the requested service 214. Then, the service provider 210 may access the available resources through a functional block configured to communicate between a first device and a second device associated with the tenant 220.

[0075] As an example, if tenant-specific resources are required to support the service 214 of the tenant 220 according to a service request, the service provider 210 may locate the tenant anchor 215 based on the information in the tenant profile 212 and extract the information for accessing the tenant-specific resources from the tenant profile 212. Then, the service provider 210 may extract the tenant-specific resources from the tenant 220 and associate them with the service profile 213, such as an access point or endpoint representing the resources, and access information required to access the tenant-specific resources, such as a public credential (e.g., a root certificate).

[0076] In some example embodiments, the service profile 213 may be updated based on changes in the tenant profile 212. For example, if there are changes in the tenant profile 212, the service provider 210 may obtain or extract the service profile 213 based on the mapping in, for example, the mapping table 211. Then the service provider 210 may update the service profile 213 based on the changes in the tenant profile 212. The service provider 210 may provide the requested 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 the changes in the tenant profile 212.

[0077] For example, if the tenant profile of the tenant changes, the service provider 210 may determine the identity of the service mapped to the tenant identity based on the mapping table 211 and obtain or extract the service profile identified by or associated with the identity of the service. Then, the service profile may be updated based on the changes in the tenant profile. The service provider 210 may further update the service associated with the service profile accordingly.

[0078] ​

[0079] In some example embodiments, if the associated tenant profile 212 is removed or the associated service profile 213 is removed, the mapping between the tenant 220 and the requested service 214 may be removed.

[0080] In some example embodiments, the service provider 210 in administrative domain A may be another service provider in another administrative domain, e.g., a tenant of services / resources provided by the service provider 230 in administrative domain B. The service provider 210 may determine available service providers for providing the requested service 214 and utilize further services or resources provided by the available service providers to provide the requested service 214 to the tenant 220. As an example, when providing the requested service 214, the service provider 210 may request and utilize service 234 from other service providers 230.

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

[0082] Furthermore, the proposed solution also supports separation of responsibilities and concerns for each domain and each functional block and allows importing tenant profiles from other domains, e.g., a dedicated security domain of a service provider (SP) or a federated domain of an SP alliance. When used by an operator, the proposed solution can be easily integrated with existing BSS / customer service systems such as a billing system, an authentication, authorization, and auditing system (AAA), etc. The proposed solution may further have a unique approach to manage and orchestrate services and resources regardless of multi-tenancy and allow tenants to use private resources in the execution scenario / environment of the service provider / producer.

[0083] Reference has been made to Figure 2 and 3 to describe the concepts of the present disclosure. To better understand the solution for multi-tenant management, a detailed example is now given in conjunction with Figure 4 and 5 A detailed example is given. Figure 4 FIG. 400 shows an example architecture in accordance with some example embodiments of the present disclosure. In reference Figure 4 and 5In the described example, network slicing is given as an example of a service for illustrative purposes only and without any limitation, and the proposed solution can also be applied to any other type of service. It should be noted that the scenarios described below are for illustrative purposes only and are not intended for any limitation.

[0084] First, a brief introduction to network slicing and related aspects is now given. 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. Then, each service or tenant can be provided with its own network slice, i.e., its own dedicated logical network instance, to meet the specific requirements of the tenant's service.

[0085] A network slice is defined as a logical network that provides specific network capabilities and network characteristics. A network slice instance is defined as a set of network function instances and the resources (such as computing, storage, and network resources) required to form a deployed network slice.

[0086] A single Slice / Service Type Acquisition Indicator (S-NSSAI) identifies a network slice, and the S-NSSAI includes: a Slice / Service Type (SST), which refers to the expected network slice behavior in terms of characteristics and services; and a Slice Differentiator (SD), which is optional information that supplements the Slice / Service Type to distinguish multiple network slices of the same Slice / Service Type.

[0087] For the supported characteristics and network function optimizations, network slices may vary, in which case such network slices may have different S-NSSAIs, for example, with different Slice / Service Types. An operator may deploy multiple network slices that provide exactly the same characteristics but are for different groups of UEs, for example, because they offer different committed services and / or because they are dedicated to customers, in which case such network slices may have different S-NSSAIs, for example, with the same SST but different SDs.

[0088] In view of the above, a specific service of a specific service or a specific tenant can be served by a network slice identified by an S-NSSAI (or sNSSAI). A single or multiple network slice instances can support multiple services or network slices.

[0089] However, if the tenant ID is included in the S-NSSAI or even in the service profile used to derive lower-layer requirements, there is a risk of leaking trade secrets to other administrative domains (e.g., other operators or service / resource providers). Therefore, a mechanism needs to be introduced that associates the tenant ID with the S-NSSAI but at the same time protects the business-related tenant ID from the impact of daily resource operations. Therefore, the proposed tenant management solution can be adopted.

[0090] 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. The vertical lessee NSC 420 can be regarded as Figure 2 a specific example of the lessee 220 shown in Figure 2 The NSP 410 can be regarded as Figure 2 a specific example of the service provider 210 shown in

[0091] Moreover, each of the NFVP 430 and the TNP 440 is a specific example of the service provider 230 shown in

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

[0093] In the example architecture 400, each of the mapping tables 411, 431, and 441 is implemented as an independent managed object. This is for illustrative purposes only and not for limitation. In some example embodiments, all or some of the mapping tables 411, 431, and 441 may be part of the lessee object.

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

[0095] Taking the table 450 as an example, the "(vertical) lessee ID" is an example of the lessee identifier described above with reference to Figure 2 and Figure 3 while the "sNSSAI" is an example of the identifier for requesting a service described above with reference to Figure 2 and 3 Here, the requested service is a network slice. The "NSI ID" column is an optional column of the mapping table 411 but may be required in the case of a network slice.

[0096] Suppose the NSC 420 requests services from the NSP 410 for the first time. The NSC 420 notifies (manually, automatically, or semi-automatically) the operator of a planned network slice allocation request on the NSP 410. The operator imports the lessee profile 412 of the NSC 420 from the BSS into the NSP 410, deploys a lessee anchor 415 for the lessee, and associates the lessee anchor 415 with the lessee profile 412.

[0097] As described above, the lessee anchor 415 is a functional block in the domain of the NSP 410 for accessing resources from the lessee domain of the NSC 420. It can be provided by the NSP 410 or provided by the NSC 420 as an agent running in the execution environment of the NSP 410. Similarly, the lessee anchors 435 and 445 are associated with the lessee profiles 432 and 442, respectively.

[0098] Now refer to Figure 5 , which illustrates a flowchart that depicts an example process 500 for lessee management in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the process 500 will be described with reference to Figure 4 . The process 500 can be considered an example of the process 300.

[0099] The NSC 420, as a vertical lessee, sends 502 a service request to the NSP 410 to allocate a network slice to support the NSC 420's evolved mobile broadband (eMBB) service. After receiving the service request, the NSMF 417 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. Then, the NSMF 417 may associate the sNSSAI or another suitable identifier for identifying the network slice / service with the service profile 413. The sNSSAI is specified by the operator based on slice / service / type and other differentiating characteristics (such as different UE groups, different customers / lessees, and other specific attributes, etc.).

[0100] If there is no shared TMO, the NSMF 417 generates 506 a lessee matrix object (TMO) and creates and inserts a mapping record in the TMO to map between the lessee ID and the sNSSAI, such as the example table 450. Note that one lessee ID can be associated with zero, one, or multiple sNSSAIs, but one sNSSAI can only be mapped to one lessee ID.

[0101] The NSP 410 then determines the 508 service profile 413. For example, the NSMF 417 extracts the subscriber profile 412 based on the subscriber ID, parses the policies or other information of the subscriber profile 412, and translates the policies or other information of the subscriber 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.

[0102] The NSMF provisions a new network slice instance for the required network slice / service deployment 510 or allocates an existing network slice instance for the service according to the attributes / requirements in the service profile 413. Although it is assumed in these example embodiments described herein that a new network slice instance will be provisioned for the service, other scenarios are possible.

[0103] If subscriber-specific resources are required to support the service of the NSC 420 according to the service request, the NSMF 417 may locate the subscriber anchor 415 based on the information in the subscriber profile 412, extract the access information for accessing the subscriber-specific resources from the subscriber profile 412, and extract the subscriber-specific resources from the NSC 420 and associate them with, for example, the service profile 413 represented as an access point or endpoint of the resource, and the access information required to access the resource, such as a common credential (e.g., a root certificate).

[0104] Then, the NSP 410 provides a request for service to the NSC 420. For example, the NSMF 417 decomposes 512 the requirements / attributes of the service profile 413 into more specific attributes of a lower-level service profile 416, which may be a slice profile in this example. If necessary, the corresponding sNSSAI may be transferred to the lower-level service profile 416.

[0105] The NSMF 417 may invoke the 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.

[0106] The NSSMF 418 interprets the attributes in the lower-level service profile 416 and determines to create a dedicated Network Slice Instance (NSSI) for the service 414, or update an existing NSSI to support the service 414. Then, if the NSS needs to constitute a sub-NSS, the NSSMF 418 converts the attributes into configuration parameters of a Network Function (NF), and / or converts the attributes into attributes of other lower-level service profiles 416, and / or converts the attributes into a Network Service Descriptor if virtualized resources are needed to build the NSS instance. If needed, the sNSSAI can be transferred to the configuration parameters of the NF and / or other lower-level service profiles 416.

[0107] The NSSMF 418 invokes the MnS(s) provided by the NFMF 419 and / or other NSSMFs and / or other MnFs to deploy or configure the relevant resources based on the attributes in the lower-level service profile 416.

[0108] In some example embodiments, virtualized resources are supported to deploy the NSS instance. The tenant profile 432 for the NSP 410 is generated or imported in the NFVP 430 that can provide virtualized resources for the NSP 410. The tenant anchor 435 provided by the NSP 410 or NFVP 430 is deployed in the NFVP 430 to proxy messages between the NFVP 430 and the NSP 410. If the NSP 410 does not have a TMO, a tenant matrix object, such as a mapping table 431, is created in the NFVP 430.

[0109] The NSSMF 418 that manages the NSS instance in the NSP 410 invokes the function block (FB) of the NFVP 430 (e.g., NFV orchestrator) at 514 to deploy the network service. The FB of the NFVP 430 can extract 516 the tenant ID of the NSP 410 from the request, create a Network Service (NS) instance according to the request and generate a record in the mapping table 431 to map the tenant ID of the NSP 410 to the NSID, and respond 518 to the NSSMF 418.

[0110] After successfully deploying and configuring the resources, the NSSMF 418 sends a response or notification to the NSMF 417. The NSMF 417 accordingly creates 520 a network slice instance and sends 522 the sNSSAI of the network slice / service to the NSC 420. In one example embodiment, the NSMF 417 can return the network slice instance ID as a service business model to the NSC 420 in the network slice.

[0111] Although not described, the NSP 410 can also request and utilize services / resources from the TNP 440.

[0112] In the above Scenario 1, the vertical lessee NSC 420 requests the NSP 410 to allocate a network slice for the eMBB service. More scenarios are described below. In Scenario 2 of the deallocation of network slices / services, assume that the network slice for the eMBB service has been allocated to the vertical lessee NSC 420 and a tenant matrix object (TMO), such as the mapping table 411, has been created for the NSC 420, and the mapping between the tenant ID and the service ID is in the mapping table 411.

[0113] After receiving a request to deallocate a network slice / service from the NSC 420 of the vertical lessee, the NSMF 417 of the NSP 410 terminates the resources referenced by the sNSSAI of the service. The NSMF 417 can terminate the entire network slice instance serving the network slice / service identified by the sNSSAI, or update the network slice instance to only terminate the resources related to the sNSSAI.

[0114] To terminate or update the network slice instance, the NSMF 417 can call the relevant NSSMF 418 to deallocate the resources related to the sNSSAI. The NSSMF 418 can terminate the entire NSSI or update the NSSI accordingly.

[0115] To terminate or update the NSSI, the NSSMF 418 can call the NFMF 419 and / or other NSSMFs and / or MnFs in other domains to terminate the relevant resources. In one exemplary embodiment, the NSSMF 418 can call the NFMF 419 to remove the sNSSAI from the sNSSAI list attribute of the Managed Function. In another exemplary embodiment, the NSSMF 418 can call, for example, the NFV orchestrator to terminate the network service instance or virtualized network function instance related to the sNSSAI.

[0116] After successfully deallocating the network slice / service, the NSMF 417 removes the relevant record of the mapping between the tenant ID of the NSC 420 and the sNSSAI from the mapping table 411. Then the NSMF 417 sends a response to the NSC 420.

[0117] In Scenario 3 of updating the tenant profile, assume that multiple network slices for eMBB, ultra-reliable low-latency communication (uRLLC), or massive Internet of Things (mIOT) services have been allocated to a vertical lessee, such as the NSC 420. Also assume that a TMO has been created for the tenant and the mapping between the tenant ID of the NSC 420 and the service ID has been created in the TMO.

[0118] Due to the policy changes of NSC 420 (such as the organizational policy changes of NSC 420, the rule changes in the industry to which NSC 420 belongs, etc.), NSC 420 triggers the update of the lessee object and the lessee profile 412 in NSP 410 or other BSS or OSS of the operator.

[0119] The NSMF 417 of NSP 410 can accordingly update the lessee profile 412. In addition, the NSMF 417 can extract all sNSSAIs associated with the lessee ID, update the service profiles identified by the sNSSAIs, and finally modify the relevant network slices / services according to the updated attributes / requirements of the service profiles. Then, the NSMF 417 can notify NSC 420 about the changes in the network slices / services.

[0120] In scenario 4 of removing the lessee profile, it is assumed that all network slices / services have been deallocated from NSP410 and the lessee or NSP 410 has decided to terminate the contract between them.

[0121] The lessee or the operator triggers the deletion of the lessee object and the lessee profile from NSP 410 and other operator systems. The NSMF 417 terminates the lessee anchor 415 from NSP 410. In the case where the mapping table 411 is dedicated to the lessee, the NSMF 417 can remove the entire mapping table 411 from NSP 410. In the case where the mapping table 411 contains entries or records for another lessee, the NSMF 417 can only remove the entries corresponding to that lessee.

[0122] It should be understood that the actions described with respect to the functions in NSP 410 can be implemented by another function. For example, in the above scenarios, all lessee-related actions are described as being completed by the NSMF 417. In other example embodiments, those lessee-related actions, such as creating, removing, updating TMO, deploying, terminating TA, retrieving and interpreting the lessee ID and lessee policy, etc., can be completed by another MF in NSP 410.

[0123] Reference will be made to Figures 6 to 7 to describe more details of example embodiments according to the present disclosure.

[0124] Figure 6 The flowchart of an example method 600 according to some example embodiments of the present disclosure is shown. The method 600 can be implemented on any suitable device. For example, the method 600 can be implemented at a first device associated with a service provider 210 as shown in Figure 2 For the purpose of discussion, the method 600 will be described with reference to Figure 2

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

[0126] In some example embodiments, generating the mapping includes: determining a first identifier for the lessee and a second identifier for the requested service; and adding an entry to a mapping table maintained at the first device, the entry mapping the first identifier to the second identifier.

[0127] In some example embodiments, the mapping table is an independent object or part of an object corresponding to the lessee.

[0128] In some example embodiments, the mapping table further includes a second entry mapping the first identifier to a third identifier for a further service requested by the lessee.

[0129] In some example embodiments, the mapping table further includes a third entry mapping a fourth identifier for another lessee to a fifth identifier for another service requested by the other lessee.

[0130] In some example embodiments, method 600 further includes: determining, based on the lessee profile, available resources of the lessee for the first device to provide the requested service; and accessing the available resources via a functional block configured for communication between the first device and the second device associated with the lessee.

[0131] In some example embodiments, method 600 further includes: obtaining a service profile based on the mapping according to a change in the lessee profile; and updating the service profile based on the change in the lessee profile.

[0132] In some example embodiments, method 600 further includes: removing the mapping between the lessee and the requested service in response to at least one of: removal of the lessee profile, or removal of the service profile.

[0133] In some example embodiments, providing the requested service includes: determining available service providers for the first device; and utilizing further services or resources provided by the available service providers.

[0134] In some example embodiments, method 600 further includes: generating a lessee profile based on information for supporting the service for the lessee; or receiving a lessee profile generated by another device different from the first device.

[0135] In some example embodiments, the first device is a device at a service provider and the second device is a device at a lessee.

[0136] Figure 7 A flowchart of an example method 700 in accordance with some example embodiments of the present disclosure is shown. The method 700 may be implemented on any suitable device. For example, as Figure 2 shown, the method 700 may be implemented at a second device in the lessee 220. For purposes of discussion, the method 700 will be described with reference to Figure 2 to describe the method 700.

[0137] At block 710, the second device sends a request from the lessee for a service to the first device. At block 720, the second device receives the requested service from the first device and provides the requested service at least in part based on a service profile of the requested service, the service profile including service requirements for the requested service, the service profile being determined based on a mapping between the lessee and the requested service and a lessee profile for the lessee, the lessee profile including information for supporting the service for the lessee.

[0138] In some example embodiments, the first device is a device at a service provider and the second device is a device at a lessee.

[0139] In some example embodiments, a device capable of performing the method 600 may include means for performing the respective steps of the method 600. The means may be implemented in any suitable form. For example, the means may be implemented in circuitry or a software module.

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

[0141] In some example embodiments, the means for generating the mapping includes: means for determining a first identifier for the lessee and a second identifier for the requested service; and means for adding an entry in a mapping table maintained at the first device that maps the first identifier to the second identifier.

[0142] In some example embodiments, the mapping table is an independent object or part of an object corresponding to the lessee.

[0143] In some example embodiments, the mapping table further includes a second entry that maps the first identifier to a third identifier for further services requested by the lessee.

[0144] In some example embodiments, the mapping table further includes a third entry that maps a fourth identifier for another lessee to a fifth identifier for another service requested by the other lessee.

[0145] In some example embodiments, the device further includes: means for determining, based on the lessee profile, the available resources of the lessee for the first device to provide a requested service; and means for accessing the available resources through a functional block configured to communicate between the first device and a second device associated with the lessee.

[0146] In some example embodiments, the device further includes: means for obtaining a service profile based on the mapping according to changes in the lessee profile; and means for updating the service profile based on changes in the lessee profile.

[0147] In some example embodiments, the device further includes: means for removing the mapping between the lessee and the requested service in response to at least one of: removal of the lessee profile, or removal of the service profile.

[0148] In some example embodiments, the means for providing the requested service 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.

[0149] In some example embodiments, the device further includes: means for generating a lessee profile based on information about services supporting the lessee; or means for receiving a lessee profile generated by another device different from the first device.

[0150] In some example embodiments, the first device is a device at the service provider and the second device is a device at the lessee.

[0151] In some example embodiments, a device capable of performing method 700 may include means for performing the respective steps of method 700. The means may be implemented in any suitable form. For example, the means may be implemented in circuitry or software modules.

[0152] In some example embodiments, the apparatus includes: means for sending a lessee's request for a service to a first device and a second device; and means for receiving a request for a service from the first device and providing the requested service at least in part based on a service profile for the requested service, the service profile including service requirements for the requested service, the service profile being determined based on a mapping between the lessee and the requested service and a lessee profile for the lessee, the lessee profile including information for supporting services for the lessee.

[0153] In some example embodiments, the first device is a device at a service provider and the second device is a device at a lessee.

[0154] Figure 8 FIG. 8 is a simplified block diagram of an apparatus 800 suitable for implementing embodiments of the present disclosure. The apparatus 800 may be provided, for example, as a first device associated with a service provider or a second device associated with a lessee, 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.

[0155] The communication module 840 is for two-way communication. The communication module 840 has at least one antenna to facilitate communication. The communication interface may represent any interface necessary for communicating with other network elements.

[0156] As a non-limiting example, the processor 810 may be any type suitable for a local technical network and may include one or more of the following: a general-purpose computer, a special-purpose computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture. The apparatus 1200 may have multiple processors, such as an application-specific integrated circuit chip that is subordinate in time to a clock synchronized with a main processor.

[0157] The memory 820 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, read-only memory (ROM) 824, electrically programmable read-only memory (EPROM), flash memory, hard disk, compact disk (CD), digital video disk (DVD), and other magnetic storage and / or optical storage. Examples of volatile memories include, but are not limited to, random access memory (RAM) 822 and other volatile memories that do not persist during a power outage.

[0158] The computer program 830 includes computer-executable instructions executed by the associated processor 810. The program 830 may be stored in the ROM 820. The processor 810 may perform any suitable actions and processes by loading the program 830 into the RAM 820.

[0159] Embodiments of the present disclosure can be implemented by program 830, such that device 800 can execute any process of the present disclosure as discussed with reference to Figures 6 to 7 the present disclosure. Embodiments of the present disclosure can also be implemented by hardware or a combination of software and hardware.

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

[0161] Generally, various embodiments of the present disclosure can be implemented in hardware or special-purpose circuits, software, logic, or any combination thereof. Some aspects can be implemented in hardware, while other aspects can be implemented in firmware or software executable by a controller, microprocessor, or other computing device. Although aspects of the embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that the block diagrams, devices, systems, techniques, or methods described herein can be implemented in the following ways: non-limiting examples, hardware, software, firmware, special-purpose circuits or logic, general-purpose hardware or a controller or other computing device, or some combination thereof.

[0162] 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 includes computer-executable instructions, such as instructions included in program modules, which are executed in a device on a target real or virtual processor to execute method 600 or 700 described above with reference to Figure 6 and Figure 7 described. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. In various embodiments, the functions of program modules can be combined or split as needed among program modules. The machine-executable instructions for program modules can be executed locally or within a distributed device. In a distributed device, program modules can be located in local and remote storage media.

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

[0164] In the context of the present disclosure, the computer program code or related data can be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations as described above. Examples of carriers include signals, computer-readable media, and the like.

[0165] The computer-readable media can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or apparatuses, or any suitable combination of the foregoing. More specific examples of the computer-readable storage media will include an electrical connection having one or more wires, a portable computer floppy disk, 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 above.

[0166] Furthermore, although the operations are described in a specific order, this should not be construed as requiring that the operations be performed in the specific order shown or in sequential order, or that all of the shown operations be performed to obtain the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to a particular embodiment. Certain features described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, the various features described in the context of a single embodiment can also be implemented separately or in any suitable sub-combination in multiple embodiments.

[0167] Although the present disclosure has been described in a language specific to structural features and / or method acts, it should be understood that the present disclosure defined in the appended claims is not necessarily limited to the above specific features or acts. On the contrary, the above specific features and acts are disclosed as example forms for implementing the claims.

Claims

1. The first device for a lessee service, comprising: At least one processor; And At least one memory, which includes computer program code; The at least one memory and the computer program code are configured to use the at least one processor to cause the first device to at least: Based on the determination of the lessee's requested service, generate a mapping between the lessee and the requested service, including: Determine a first identifier for the lessee and a second identifier for the requested service, where the second identifier includes an identifier of a service profile associated with the requested service; and Add a first entry in the mapping table maintained by the first device that maps the first identifier to the second identifier; Based on the mapping and the lessee profile for the lessee, determine the service profile of the requested service, the lessee profile including information for supporting the service for the lessee, and the service profile including service requirements for the requested service; and Provide the requested service to a second device associated with the lessee at least partially based on the service profile; Where determining the service profile of the requested service based on the mapping and the lessee profile for the lessee at least includes: Mapping the policies or rules in the lessee profile to the attributes or service requirements of the service profile; and Updating the service profile based on changes in the lessee profile.

2. The first device for the lessee service according to claim 1, wherein, The mapping table is an independent object corresponding to the lessee or a part of an object.

3. The first device for lessee services according to claim 1, wherein, The mapping table further includes a second entry that maps the first identifier to a third identifier for another service requested by the lessee.

4. The first device for the lessee service according to claim 1, wherein, The mapping table further includes a third entry that maps a fourth identifier for another lessee to a fifth identifier for another service requested by the other lessee.

5. The first device for a lessee service according to claim 1, wherein the first device is further caused to: Determine the available resources of the lessee based on the lessee profile for providing the requested service by the first device; and Access the available resources through a functional block configured for communication between the first device and the second device associated with the lessee.

6. The first apparatus for the lessee service according to claim 1, wherein, The first device is further caused to: Based on changes in the lessee profile, obtain the service profile based on the mapping.

7. The first device for a lessee service according to claim 1, wherein the first device is further caused to: Remove the mapping between the lessee and the requested service at least in response to one of the following: Removing the lessee profile, or Removing the service profile.

8. The first apparatus for lessee services according to claim 1, wherein, The first device provides the requested service by: Determining an available service provider for the first device; And Utilizing another service or resource provided by the available service provider.

9. The first apparatus for lessee services according to claim 1, wherein, The first device is further caused to: Generate the lessee profile based on the information for supporting the service for the lessee; or Receive the tenant profile generated by another device different from the first device.

10. The first apparatus for the lessee service according to claim 1, wherein, The first device is a device at a service provider, and the second device is a device at the tenant.

11. A second device for tenant services, comprising: At least one processor; And At least one memory including computer program code; The at least one memory and the computer program code are configured to, using the at least one processor, cause the second device to at least: Send a tenant request for a service to a first device; And Receive the requested service from the first device and provide the requested service at least partially based on a service profile of the requested service, the service profile including service requirements for the requested service, the service profile being determined based on a mapping between the tenant and the requested service and a tenant profile for the tenant, the tenant profile including information for supporting services for the tenant; Wherein the mapping between the tenant and the requested service includes: a mapping between a first identifier for the tenant and a second identifier for the requested service, wherein the second identifier includes an identifier of a service profile associated with the requested service; Wherein determining the service profile at least includes: Mapping policies or rules in the tenant profile to attributes or service requirements of the service profile; and Updating the service profile based on changes in the tenant profile.

12. The second apparatus for the lessee service according to claim 11, wherein, The first device is a device at a service provider, and the second device is a device at the tenant.

13. A method for tenant services, comprising: Generating, at a first device, a mapping between the tenant and the requested service according to a determination of the service requested by the tenant, including: Determining a first identifier for the tenant and a second identifier for the requested service, wherein the second identifier includes an identifier of a service profile associated with the requested service; and Adding a first entry mapping the first identifier to the second identifier in a mapping table maintained by the first device; Determining a service profile for the requested service based on the mapping and a tenant profile for the tenant, the tenant profile including information for supporting services for the tenant, the service profile including service requirements for the requested service; and Providing the requested service to a second device associated with the tenant at least partially based on the service profile; Wherein determining the service profile for the requested service based on the mapping and a tenant profile for the tenant at least includes: Mapping policies or rules in the tenant profile to attributes or service requirements of the service profile; and Updating the service profile based on changes in the tenant profile.

14. The method for the lessee service according to claim 13, wherein, The mapping table is an independent object or part of an object corresponding to the tenant.

15. The method for lessee services as claimed in claim 13, wherein, The mapping table further includes a second entry that maps the first identifier to a third identifier for further services requested by the lessee.

16. The method for the lessee service according to claim 13, wherein, The mapping table further includes a third entry that maps a fourth identifier for another lessee to a fifth identifier for another service requested by the other lessee.

17. The method for lessee services according to claim 13, further comprising: Determining available resources of the lessee based on the lessee profile for the first device to provide the requested service; and Accessing the available resources through a functional block configured to communicate between the first device and the second device associated with the lessee.

18. The method for lessee services according to claim 13, further comprising: Obtaining the service profile based on the mapping according to changes in the lessee profile.

19. The method for lessee services according to claim 13, further comprising: Removing the mapping between the lessee and the requested service in response to at least one of the following: Removing the lessee profile, or Removing the service profile.

20. The method for lessee services as claimed in claim 13, wherein, Providing the requested service includes: Determining an available service provider for the first device; and Utilizing another service or resource provided by the available service provider.

21. The method for lessee services according to claim 13, further comprising: Generating the lessee profile based on information supporting the service for the lessee; or Receiving a lessee profile generated by another device different from the first device.

22. The method for the lessee service according to claim 13, wherein, The first device is a device at a service provider, and the second device is a device at the lessee.

23. A method for lessee services, comprising: Sending a request for a service from a lessee to a first device and at a second device; and Receiving the requested service from the first device, and providing the requested service at least in part based on a service profile of the requested service, the service profile including service requirements for the requested service, the service profile being determined based on a mapping between the lessee and the requested service and a lessee profile for the lessee, the lessee profile including information for supporting the service for the lessee; wherein the mapping between the lessee and the requested service includes: a mapping between a first identifier for the lessee and a second identifier for the requested service, wherein the second identifier includes an identifier of a service profile associated with the requested service; wherein determining the service profile at least includes: Mapping policies or rules in the lessee profile to attributes or service requirements of the service profile; and Updating the service profile based on changes in the lessee profile.

24. The method for the lessee service according to claim 23, wherein, The first device is a device at a service provider, and the second device is a device at the lessee.

25. An apparatus for lessee services, comprising: An apparatus for generating a mapping between the lessee and the requested service at a first device according to a determination of a service requested by a lessee. An apparatus for determining a service profile of the requested service based on the mapping and a lessee profile for the lessee, the lessee profile including information for supporting services for the lessee, the service profile including service requirements of the requested service; and An apparatus for providing the requested service to a second device associated with the lessee at least in part based on the service profile; wherein generating the mapping between the lessee and the requested service includes: Determining a first identifier for the lessee and a second identifier for the requested service, wherein the second identifier includes an identifier of a service profile associated with the requested service; and Adding a first entry in a mapping table maintained by the first device that maps the first identifier to the second identifier; wherein determining the service profile of the requested service based on the mapping and the lessee profile for the lessee at least includes: Mapping policies or rules in the lessee profile to attributes or service requirements of the service profile; and Updating the service profile based on changes in the lessee profile.

26. An apparatus for lessee services, comprising: An apparatus for sending a lessee's request for a service to a first device and at a second device; and An apparatus for receiving the requested service from the first device and providing the requested service at least in part based on a service profile of the requested service, the service profile including service requirements for the requested service, the service profile being determined based on a mapping between the lessee and the requested service and a lessee profile for the lessee, the lessee profile including information for supporting services for the lessee; wherein the mapping between the lessee and the requested service includes: a mapping between a first identifier for the lessee and a second identifier for the requested service, wherein the second identifier includes an identifier of a service profile associated with the requested service; wherein determining the service profile at least includes: Mapping policies or rules in the lessee profile to attributes or service requirements of the service profile; and Updating the service profile based on changes in the lessee profile.

27. A computer-readable medium, comprising program instructions for causing a device to at least perform the method according to any one of claims 13 - 22.

28. A computer-readable medium, comprising program instructions for causing a device to at least perform the method according to any one of claims 23 - 24.

Images