WO2023167571A1

WO2023167571A1 - Method and system for management services authorization

Info

Publication number: WO2023167571A1
Application number: PCT/KR2023/003036
Authority: WO
Inventors: Deepanshu Gautam
Original assignee: Samsung Electronics Co., Ltd.
Priority date: 2022-03-04
Filing date: 2023-03-06
Publication date: 2023-09-07

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. A method according to an embodiment includes transmitting an on-board application programming interface (API) invoker request to an exposure governance management function (EGMF) device (200) to register an MnS consumer device (100) with the EGMF device (200), the on-board API invoker request comprises an MnS consumer device type. The method further includes transmitting a discover service API request to the EGMF device (200) to discover the at least one available management service. The method further includes receiving a discover service API response from the EGMF device (200) based on a published service API available at the EGMF device (200), where the discover service API response comprises a service API description describing the at least one available management service. The method further includes obtaining authorization from the EGMF device (200) to access the at least one management service of an MnS producer device (300) based on the MnS consumer device type and the obtained authorization.

Description

METHOD AND SYSTEM FOR MANAGEMENT SERVICES AUTHORIZATION

The disclosure generally relates to wireless communication, and more specifically relates to a method and a system for management services (MnS) authorization in the wireless communication.

5G mobile communication technologies define broad frequency bands such that high transmission rates and new services are possible, and can be implemented not only in "Sub 6GHz" bands such as 3.5GHz, but also in "Above 6GHz" bands referred to as mmWave including 28GHz and 39GHz. In addition, it has been considered to implement 6G mobile communication technologies (referred to as Beyond 5G systems) in terahertz bands (for example, 95GHz to 3THz bands) in order to accomplish transmission rates fifty times faster than 5G mobile communication technologies and ultra-low latencies one-tenth of 5G mobile communication technologies.

At the beginning of the development of 5G mobile communication technologies, in order to support services and to satisfy performance requirements in connection with enhanced Mobile BroadBand (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), there has been ongoing standardization regarding beamforming and massive MIMO for mitigating radio-wave path loss and increasing radio-wave transmission distances in mmWave, supporting numerologies (for example, operating multiple subcarrier spacings) for efficiently utilizing mmWave resources and dynamic operation of slot formats, initial access technologies for supporting multi-beam transmission and broadbands, definition and operation of BWP (BandWidth Part), new channel coding methods such as a LDPC (Low Density Parity Check) code for large amount of data transmission and a polar code for highly reliable transmission of control information, L2 pre-processing, and network slicing for providing a dedicated network specialized to a specific service.

Currently, there are ongoing discussions regarding improvement and performance enhancement of initial 5G mobile communication technologies in view of services to be supported by 5G mobile communication technologies, and there has been physical layer standardization regarding technologies such as V2X (Vehicle-to-everything) for aiding driving determination by autonomous vehicles based on information regarding positions and states of vehicles transmitted by the vehicles and for enhancing user convenience, NR-U (New Radio Unlicensed) aimed at system operations conforming to various regulation-related requirements in unlicensed bands, NR UE Power Saving, Non-Terrestrial Network (NTN) which is UE-satellite direct communication for providing coverage in an area in which communication with terrestrial networks is unavailable, and positioning.

Moreover, there has been ongoing standardization in air interface architecture/protocol regarding technologies such as Industrial Internet of Things (IIoT) for supporting new services through interworking and convergence with other industries, IAB (Integrated Access and Backhaul) for providing a node for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner, mobility enhancement including conditional handover and DAPS (Dual Active Protocol Stack) handover, and two-step random access for simplifying random access procedures (2-step RACH for NR). There also has been ongoing standardization in system architecture/service regarding a 5G baseline architecture (for example, service based architecture or service based interface) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) for receiving services based on UE positions.

As 5G mobile communication systems are commercialized, connected devices that have been exponentially increasing will be connected to communication networks, and it is accordingly expected that enhanced functions and performances of 5G mobile communication systems and integrated operations of connected devices will be necessary. To this end, new research is scheduled in connection with eXtended Reality (XR) for efficiently supporting AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality) and the like, 5G performance improvement and complexity reduction by utilizing Artificial Intelligence (AI) and Machine Learning (ML), AI service support, metaverse service support, and drone communication.

Furthermore, such development of 5G mobile communication systems will serve as a basis for developing not only new waveforms for providing coverage in terahertz bands of 6G mobile communication technologies, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), array antennas and large-scale antennas, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-dimensional space multiplexing technology using OAM (Orbital Angular Momentum), and RIS (Reconfigurable Intelligent Surface), but also full-duplex technology for increasing frequency efficiency of 6G mobile communication technologies and improving system networks, AI-based communication technology for implementing system optimization by utilizing satellites and AI (Artificial Intelligence) from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technology for implementing services at levels of complexity exceeding the limit of UE operation capability by utilizing ultra-high-performance communication and computing resources.

The disclosure may provide a method and a system for management services (MnS) authorization in the wireless communication.

This technical solution is provided to introduce a selection of concepts, in a simplified format, that are further described in the detailed description of the disclosure. This technical solution is neither intended to identify key or essential inventive concepts of the disclosure nor is it intended for determining the scope of the disclosure.

According to one embodiment of the disclosure, a method for accessing at least one management service of a management services (MnS) producer device by an MnS consumer device is disclosed. The method includes transmitting, by an MnS consumer device, an on-board application programming interface (API) invoker request to an exposure governance management function (EGMF) device to register the MnS consumer device with the EGMF device, wherein the on-board API invoker request comprises an MnS consumer device type. The method further includes transmitting, by the MnS consumer device, a discover service API request to the EGMF device to discover the at least one available management service. The method further includes obtaining, by the MnS consumer device, authorization from the EGMF device to access the at least one available management service. The method further includes accessing, by the MnS consumer device, the at least one management service of the MnS producer device based on the MnS consumer device type and the obtained authorization.

According to another embodiment of the disclosure, a method for authorizing at least one management service of the MnS producer device by EGMF device is disclosed. The method includes receiving, by the EGMF device, the on-board API invoker request from the MnS consumer device to register the MnS consumer device with the EGMF device, wherein the on-board API invoker request comprises the MnS consumer device type. The method further includes receiving, by the EGMF device, a publish service API request from the MnS producer device, wherein the publish service API request comprises a service API description. The method further includes receiving, by the EGMF device, the discover service API request from the MnS consumer device to discover the at least one available management service. The method further includes authorizing, by the EGMF device, the MnS consumer device to provide access to the at least one management service.

According to another embodiment of the disclosure, a system for authorizing the MnS consumer device to access the at least one management service of the MnS producer device is disclosed. The system includes an MnS access controller coupled with a processor, a memory, and a communicator. The MnS access controller is configured to transmit the on-board API invoker request to the EGMF device to register the MnS consumer device with the EGMF device, wherein the on-board API invoker request comprises the MnS consumer device type. The MnS access controller is further configured to transmit the discover service API request to the EGMF device to discover the at least one available management service. The MnS access controller is further configured to receive the discover service API response from the EGMF device based on the published service API available at the EGMF device, wherein the discover service API response comprises the service API description describing the at least one available management service. The MnS access controller is further configured to obtain authorization from the EGMF device to access the at least one available management service. The MnS access controller is further configured to access the at least one management service of the MnS producer device based on the MnS consumer device type and the obtained authorization.

According to another embodiment of the disclosure, a system for authorizing the at least one management service of the MnS producer device by the EGMF device is disclosed. The system includes an MnS access controller coupled with a processor, a memory, and a communicator. The MnS access controller is configured to receive the on-board API invoker request from the MnS consumer device to register the MnS consumer device with the EGMF device, wherein the on-board API invoker request comprises the MnS consumer device type. The MnS access controller is further configured to receive the publish service API request from the MnS producer device, wherein the publish service API request comprises the service API description. The MnS access controller is further configured to receive the discover service API request from the MnS consumer device to discover the at least one available management service. The MnS access controller is further configured to authorize the MnS consumer device to provide access to the at least one management service.

To further clarify the advantages and features of the disclosure, a more particular description of the disclosure will be rendered by reference to specific embodiments thereof, which are illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the disclosure and are therefore not to be considered limiting of its scope. The disclosure will be described and explained with additional specificity and detail in the accompanying drawings.

These and other features, aspects, and advantages of the disclosure will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:

FIG. 1 illustrates an existing common API framework (CAPIF) functional architecture defines a framework for exposing 3GPP northbound API to an external consumer (API invoker), to which an embodiment is applicable;

FIG. 2 illustrates a mapping of 3GPP management components with CAPIF components device for accessing the at least one management service of the MnS producer device, according to an embodiment as disclosed herein;

FIG. 3 illustrates a scenario in which several types of MnS consumers access management services/capabilities/5G management capabilities provided by an MnS producer, according to an embodiment as disclosed herein;

FIG. 4A illustrates a block diagram of an MnS consumer device for accessing at least one management service of an MnS producer device, according to an embodiment as disclosed herein;

FIG. 4B illustrates a block diagram of an exposure governance management function (EGMF) device for authorizing at least one management service of the MnS producer device, according to an embodiment as disclosed herein;

FIG. 5 is a flow diagram illustrating a method for accessing the at least one management service of the MnS producer device, according to an embodiment as disclosed herein;

FIG. 6 is a flow diagram illustrating a method for authorizing the at least one management service of the MnS producer device, according to an embodiment as disclosed herein;

FIG. 7A illustrates a sequence flow diagram illustrating a method for managing service authorization for exposure governance of 5G management capabilities, according to an embodiment as disclosed herein;

FIG. 7B illustrates a sequence flow diagram illustrating a method for managing service authorization for exposure governance of 5G management capabilities, according to an embodiment as disclosed herein;

FIG. 8 illustrates an electronic device according to an embodiment as disclosed herein; and

FIG. 9 illustrates a node according to an embodiment of as disclosed herein.

Further, skilled artisans will appreciate that elements in the drawings are illustrated for simplicity and may not have necessarily been drawn to scale. For example, the flow charts illustrate the method in terms of the most prominent steps involved to help to improve understanding of aspects of the disclosure. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the disclosure so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

For the purpose of promoting an understanding of the principles of the disclosure, reference will now be made to the embodiment illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the disclosure is thereby intended, such alterations and further modifications in the illustrated system, and such further applications of the principles of the disclosure as illustrated therein being contemplated as would normally occur to one skilled in the art to which the disclosure relates.

It will be understood by those skilled in the art that the foregoing general description and the following detailed description are explanatory of the disclosure and are not intended to be restrictive thereof.

Reference throughout this specification to "an aspect", "another aspect" or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the disclosure. Thus, appearances of the phrase "in an embodiment", "in one embodiment", "in another embodiment", and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

The terms "comprise", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such process or method. Similarly, one or more devices or sub-systems or elements or structures or components proceeded by "comprises... a" does not, without more constraints, preclude the existence of other devices or other sub-systems or other elements or other structures or other components or additional devices or additional sub-systems or additional elements or additional structures or additional components.

The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. Also, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments. The term "or" as used herein, refers to a non-exclusive or unless otherwise indicated. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein can be practiced and to further enable those skilled in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

As is traditional in the field, embodiments may be described and illustrated in terms of blocks that carry out a described function or functions. These blocks, which may be referred to herein as units or modules or the like, are physically implemented by analog or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware and software. The circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like. The circuits constituting a block may be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware to perform some functions of the block and a processor to perform other functions of the block. Each block of the embodiments may be physically separated into two or more interacting and discrete blocks without departing from the scope of the disclosure. Likewise, the blocks of the embodiments may be physically combined into more complex blocks without departing from the scope of the disclosure.

The accompanying drawings are used to help easily understand various technical features and it should be understood that the embodiments presented herein are not limited by the accompanying drawings. As such, the disclosure should be construed to extend to any alterations, equivalents, and substitutes in addition to those which are particularly set out in the accompanying drawings. 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 generally only used to distinguish one element from another.

Throughout this disclosure, the terms "MnS consumer", "consumer" and "MnS consumer device" are used interchangeably. The terms "MnS producer" and "MnS producer device" are used interchangeably.

Referring now to the drawings, and more particularly to FIGS. 1 to 9, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments.

In general, fifth generation (5G) system consists of a 5G access network (AN), a 5G Core Network (CN), and a user equipment (UE), according to 3^rd generation partnership project (3GPP) technical specification (TS) 23.501. The 5G system is expected to be capable of providing optimized support for a wide range of communication services, traffic loads, and end-user communities. Vehicle-to-everything (V2X) services, is a non-limiting example of communication services that use network slicing. The 5G system aims to improve its ability to meet key performance indicators (KPIs) required by emerging V2X applications. The requirements for these advanced applications are more stringent in terms of data rate, reliability, latency, communication range, and speed. 5G seamless enhanced mobile broadband (eMBB), as one of the key technologies to enable the network slicing, fixed mobile convergence (FMC), which includes wireless-to-everything (WTTx) and fiber-to-the-everything (FTTx), is expected to provide native support for the network slicing.

For optimization and resource efficiency, the 5G system will select the most appropriate 3GPP or non-3GPP access technology for a communication service, potentially allowing multiple access technologies to be used simultaneously for one or more services active on the UE, massive internet of things (IoT) connections- support for massive internet of things (mIoT) brings many new requirements in addition to MBB enhancements. Communication services with massive IoT connections such as smart households, smart grids, smart agriculture, and smart meter will require the support of a large number and high-density IoT devices to be efficient and cost-effective. Operators can use one or more network slice instances to provide these communication services, which require similar network characteristics to different vertical industries. 3GPP TS 28.530 and 28.531 define the management of network slice in 5G networks. It also defines the concept of communication services, which are provided using one or multiple network slices. A network slice instance (NSI) may support multiple communication service instances (CSI). Similarly, a CSI may utilize multiple NSIs.

FIG. 1 illustrates an existing common API framework (CAPIF) functional architecture defines a framework for exposing 3GPP northbound API to an external consumer (API invoker), to which an embodiment is applicable.

The existing common API framework (CAPIF) functional architecture defines a framework for exposing 3GPP northbound API to an external consumer (e.g., API invoker) as shown in FIG. 1. The CAPIF is hosted within a PLMN operator network/PLMN trust domain. The API invoker is typically provided by a 3^rd party application provider who has a service agreement with the PLMN operator network. The API invoker may reside within the same trust domain as the PLMN operator network. In a reference point-based model, the API invoker within the PLMN trust domain interacts with the CAPIF via CAPIF-1 and CAPIF-2. The API invoker from outside the PLMN trust domain interacts with the CAPIF via CAPIF-1e and CAPIF-2e. An API exposing function, an API publishing function, and an API management function of an API provider domain (together known as API provider domain functions) within the PLMN trust domain interact with the CAPIF core function via CAPIF-3, CAPIF-4, and CAPIF-5, respectively.

The existing wireless communication systems have some limitations, such as the functionality of exposing MnS to thirdparty consumers (e.g., API invoker), which is not sufficiently defined in current OAM standards/ as defined in 3GPP TS 28.533. To expose the same, the functionality of the existing CAPIF functional architecture can be used. However, the existing CAPIF functional architecture is insufficient to describe the MnS that can be exposed. Further, an existing open authorization (OAuth) token mechanism does not support representing granular access authorization for the MnSes in relation to components A, B, and C of the management service. The components A, B, and C of the management domain/services are defined by 3GPP management service, as defined in 3GPP TS 28.533.

Thus, it is desired to address the above-mentioned disadvantages or other shortcomings or at least provide a useful alternative for exposure governance of 5G management capabilities.

FIG. 2 illustrates a mapping of 3GPP management components with CAPIF components device for accessing the at least one management service of an MnS producer device 300, according to an embodiment as disclosed herein.

In a disclosed method/system an EGMF device 200 is configured to implement the CAPIF functionalities. The MnS producer device 300 is configured to implement API provider domain functionalities. An MnS consumer device 100 (e.g., 100A and 100B) is configured to implement API invoker functionality. The CAPIF-2 and CAPIF-2e represent SA5-defined management services. Various interactions (for example, CAPIF-1, CAPIF-2, CAPIF-1e, CAPIF-2e, CAPIF-3, CAPIF-4, and CAPIF-5) between various elements (100A, 100B, 200, and 300) are the same as described in FIG. 1. Additionally, detailed technical details about the MnS consumer device 100, the EGMF device 200, and the MnS producer device 300, as discussed throughout the disclosure, are described in conjunction with FIGS. 3 to 7B.

The disclosed method/system offers a potential solution for exposing network slice management capability. The disclosed method/system supports exposure via CAPIF alternative-2 and exposure via CAPIF alternative-3. The disclosed method/system proposes to expose network slice management capabilities to external entities by utilizing the CAPIF framework (EGMF device 200). To support MnS exposure and authorization, the disclosed method/system necessitates extending the existing CAPIF mechanism. This includes expanding the ServiceAPIDescription to include a description of the 3GPP management services required for exposure. The disclosed method/system also includes defining a mechanism for developing exposure governance rules for granting external entities (MnS consumer device 100) granular access to the MnS. The same solution can be used to provide access to entities within a PLMN trust domain in addition to external entities.

FIG. 3 illustrates a scenario in which several types of MnS consumers access management services/capabilities/5G management capabilities provided by the MnS producer 300, according to an embodiment as disclosed herein.

There are several types of consumers (e.g., MnS consumers/API Invoker), as discussed throughout the disclosure, can access management services (MnS)/ management capabilities/5G management capabilities provided by a management domain/service (e.g., MnS producer 300/API provider domain), as shown in FIG.3.

1) Network operator (NOP) external MnS consumer device: the NOP external MnS consumer device is external to a public land mobile network (PLMN) trust domain. Example of the NOP external MnS consumer device includes, but is not limited to, application service provider (ASP), vehicle to everything (V2X), and so on.

2) Operations, administration, and maintenance (OAM) external MnS consumer device: the OAM external MnS consumer device is external to a 3^rdgeneration partnership project (3GPP) management domain. Example of the OAM external MnS consumer device includes, but is not limited to, 5G network data analytics function (NWDAF), next-generation node B (gNB), network repository function (NRF), and so on.

3) OAM internal MnS consumer device: the OAM internal MnS consumer device is internal to the 3GPP management domain. Example of the OAM internal MnS consumer device includes, but is not limited to, an element management system (EMS), network management system (NMS), operation support system (OSS), and so on. The access for each type of MnS consumer may vary depending on a business contract or an operator policy.

The exposure governance/ exposure governance intelligence defines what part of the management services (MnS) the consumer (MnS consumer device 100) is authorized to access (e.g., operation, NRM fragment, notifications), as shown in Table 1. Examples of the MnS include, but not limited to, a generic provisioning MnS, a performance assurance MnS, and so on.

[Table 1]

FIG. 4A illustrates a block diagram of the MnS consumer device 100 (e.g., API invoker) for accessing at least one management service of the MnS producer device 300 (e.g., API provider domain), according to an embodiment as disclosed herein.

In an embodiment, the MnS consumer device 100 comprises a system 101. The system 101 may include a memory 110, a processor 120, a communicator 130, and an MnS access module 140.

In one embodiment, the memory 110 stores instructions to be executed by the processor 120 to access the at least one management service of the management services (MnS) producer device, as discussed throughout the disclosure. The memory 110 may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory 110 may, in some examples, be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted that the memory 110 is non-movable. In some examples, the memory 110 can be configured to store larger amounts of information than the memory. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache). The memory 110 can be an internal storage unit, or it can be an external storage unit of the MnS consumer device 100, a cloud storage, or any other type of external storage.

The processor 120 communicates with the memory 110, the communicator 130, and the MnS access module 140. The processor 120 is configured to execute instructions stored in the memory 110 and to perform various processes for accessing the at least one management service of the MnS producer device 300, as discussed throughout the disclosure. The processor 120 may include one or a plurality of processors, maybe a general-purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and/or an Artificial intelligence (AI) dedicated processor such as a neural processing unit (NPU).

The communicator 130 is configured for communicating internally between internal hardware components and with external devices (e.g., MnS producer device 300, EGMF, etc.) via one or more networks (e.g., Radio technology). The communicator 130 includes an electronic circuit specific to a standard that enables wired or wireless communication.

In one embodiment, the MnS access module 140 may be implemented by processing circuitry such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware. The circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like.

In one embodiment, the MnS access module 140 includes an MnS registration module 141, an MnS discovery module 142, an MnS authentication module 143, and an MnS session module 144.

In one embodiment, for consumer registration procedure to access at least one management service of the MnS producer device 300, the MnS registration module 141 transmits an on-board application programming interface (API) invoker request to an exposure governance management function (EGMF) device 200 to register the MnS consumer device 100 with the EGMF device 200. The on-board API invoker request includes an MnS consumer device type, as shown in Table 1. The MnS consumer device type includes a Network Operator (NOP) external MnS consumer device, an Operations, Administration and Maintenance (OAM) external MnS consumer device, and an OAM internal MnS consumer device. The NOP external MnS consumer device is external to a Public Land Mobile Network (PLMN) trust domain, the OAM external MnS consumer device is external to a 3^rdGeneration Partnership Project (3GPP) management domain, and the OAM internal MnS consumer device is internal to the 3GPP management domain. The MnS registration module 141 then receives an on-board API invoker response from the EGMF device 200, as an acknowledgment of the on-board API invoker request, as described in conjunction with FIGS. 7A-7B.

In one embodiment, for an MnS discovery procedure to access the at least one management service of the MnS producer device 300, the MnS discovery module 142 transmits a discover service API request to the EGMF device 200 to discover the at least one available management service at the MnS producer device 300. The MnS discovery module 142 then receives a discover service API response from the EGMF device 200 based on a publish service API request available at the EGMF device 200. The discover service API response includes a service API description describing the at least one available management service, as described in conjunction with FIGS. 7A-7B.

In one embodiment, for obtaining MnS authorization procedure to access the at least one management service of the MnS producer device 300, the MnS authentication module 143 obtains authorization from the EGMF device 200 to access the at least one available management service. The MnS authentication module 143 initiates an authentication process by utilizing the EGMF device 200 and establishes a secure session over transport layer security (TLS) with the EGMF device 200. The MnS authentication module 143 transmits an open authorization version 2 (OAuth2.0) based access token request to the EGMF device 200 to obtain authorization from the EGMF device 200 to access the at least one available management service. Upon receiving the OAuth2.0 based access token request, the EGMF device 200 verifies the OAuth2.0 based access token request as defined in 3GPP TS 33.122 and generates a token (OAuth token). In one embodiment, the OAuth token is generated based on a granular access intelligence. The MnS authentication module 143 then receives an OAuth2.0 based access token response from the EGMF device 200. The OAuth2.0 based access token response includes the generated token (OAuth token). The OAuth token is generated by the EGMF device 200 based on the MnS consumer device type and an exposure governance intelligence, incorporated by referencing an Indian Provisional Application Number 202141025257. In one embodiment, the EGMF device 200 creates the granular access intelligence based on the MnS consumer device type and the service API description. The EGMF device 200 generates the token (OAuth token) based on the created granular access intelligence, as described in conjunction with FIGS. 7A-7B.

In one embodiment, for accessing the at least one management service of the MnS producer device 300, the MnS session module 144 establishes a secure session over transport layer security (TLS) with the MnS producer device 300. The MnS session module 144 transmits an access service API request to the MnS producer device 300 to access the at least one available management service of the MnS producer device 300, where the access service API request includes the token (OAuth token), which is received from the EGMF device 200. The MnS producer device 300 then verifies the token (OAuth token), authorization, and executes requested MnS operations, as defined in 3GPP TS 33.122. The MnS session module 144 receives an access service API response from the MnS producer device 300 to access the at least one available management service of the MnS producer device 300 upon successful verification of the MnS consumer device 100, where the MnS producer device 300 verifies the access MnS request based on the OAuth token.

Although FIG. 4A shows various hardware components of MnS consumer device 100, but it is to be understood that other embodiments are not limited thereon. In other embodiments, the MnS consumer device 100 may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the disclosure. One or more components can be combined to perform the same or substantially similar functions to access the at least one management service of the MnS producer device 300.

FIG. 4B illustrates a block diagram of an exposure governance management function (EGMF) device 200 for authorizing the at least one management service of the MnS producer device 300, according to an embodiment as disclosed herein.

In an embodiment, the EGMF device 200 comprises a system 201. The system 201 may include a memory 210, a processor 220, a communicator 230, and an MnS access module 240.

In one embodiment, the memory 210 stores instructions to be executed by the processor 220 for authorizing the at least one management service of the MnS producer device 300, as discussed throughout the disclosure. The memory 210 may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory 210 may, in some examples, be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted that the memory 210 is non-movable. In some examples, the memory 210 can be configured to store larger amounts of information than the memory. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache). The memory 210 can be an internal storage unit, or it can be an external storage unit of the EGMF device 200, a cloud storage, or any other type of external storage.

The processor 220 communicates with the memory 210, the communicator 230, and the MnS access module 240. The processor 220 is configured to execute instructions stored in the memory 210 and to perform various processes. The processor 220 may include one or a plurality of processors, maybe a general-purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and/or an Artificial intelligence (AI) dedicated processor such as a neural processing unit (NPU).

The communicator 230 is configured for communicating internally between internal hardware components and with external devices (e.g., MnS consumer device 100) via one or more networks (e.g., Radio technology). The communicator 230 includes an electronic circuit specific to a standard that enables wired or wireless communication.

The MnS access module 240 may be implemented by processing circuitry such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware. The circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like.

In one embodiment, the MnS access module 240 includes a publishing module 241 and an MnS authentication module 242.

In one embodiment, for the MnS publishing procedure to authorize the at least one management service of the MnS producer device 300, the publishing module 241 receives a publish service API request from the MnS producer device 300, where the publish service API request includes the service API description, as described in conjunction with FIGS. 7A-7B. Upon receiving the publish service API request, the MnS producer device 300 transmits a publish service API response to the MnS producer device 300.

In one embodiment, to authorize the at least one management service of the MnS producer device 300, the MnS authentication module 242 receives the OAuth2.0 based access token request from the MnS consumer device 100. Upon receiving the OAuth2.0 based access token request, the MnS authentication module 242 verifies the OAuth2.0 based access token request and generates the token (OAuth token) as defined. The OAuth token is generated based on the MnS consumer device type and the exposure governance intelligence. The MnS authentication module 242 then sends the OAuth2.0 based access token response to the MnS consumer device 100. The OAuth2.0 based access token response includes the generated token (OAuth token). In one embodiment, the MnS authentication module 242 creates the granular access intelligence based on the MnS consumer device type and the service API description. The MnS authentication module 242 generates the token (OAuth token) based on the created granular access intelligence.

Although FIG. 4B shows various hardware components of the EGMF device 200, but it is to be understood that other embodiments are not limited thereon. In other embodiments, the EGMF device 200 may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the disclosure. One or more components can be combined to perform the same or substantially similar functions to authorize the at least one management service of the MnS producer device 300.

FIG. 5 is a flow diagram illustrating a method 500 for accessing the at least one management service of the MnS producer device 300, according to an embodiment as disclosed herein. Steps (501 to 505) may be performed by the MnS consumer device 100.

At step 501, the method 500 includes transmitting, by the MnS consumer device 100, the on-board API invoker request to the EGMF device 200 to register the MnS consumer device 100 with the EGMF device 200, wherein the on-board API invoker request includes the MnS consumer device type. The on-board API invoker request may indicate that an interested MnS consumer device 100 wishes to access at least one management service provided by the MnS producer device 300. The MnS consumer device type includes the NOP external MnS consumer device, the OAM external MnS consumer device, and the OAM internal MnS consumer device. The NOP external MnS consumer device is external to the PLMN trust domain, the OAM external MnS consumer device is external to the 3GPP management domain, and the OAM internal MnS consumer device is internal to the 3GPP management domain.

At step 502, the method 500 includes transmitting, by the MnS consumer device 100, the discover service API request to the EGMF device 200 to discover the at least one available management service (MnS) (e.g., generic provisioning MnS), as illustrated in FIG. 1.

At step 503, the method 500 includes receiving, by the MnS consumer device 100, the discover service API response from the EGMF device 200 based on the published service API available at the EGMF device 200, wherein the discover service API response includes the service API description describing the at least one available management service. The published service API may indicate that an available MnS publishes/broadcasts to the EGMF device 200 and the discover service API may indicate that the interested MnS consumer device 100 wishes to discover at least one management service provided by the MnS producer device 300. The service API description includes the exposer detail for each type of the MnS consumer device 100, the service location, the service availability, the service reliability, and the service latency.

At step 504, the method 500 includes obtaining, by the MnS consumer device 100, the authorization from the EGMF device 200 to access the at least one available management service. In one embodiment, obtaining, by the MnS consumer device 100, authorization from the EGMF device 200 includes transmitting, by the MnS consumer device 100, the OAuth2.0 based access token request to the EGMF device 200 to obtain authorization from the EGMF device to access the at least one available management service. Subsequently, the MnS consumer device 100 may be configured to receive an OAuth2.0 based access token response from the EGMF device 200, wherein the OAuth2.0 access token response comprises an OAuth token, and the Oauth token is generated by the EGMF device 200 based on the MnS consumer device type and the exposure governance intelligence.

At step 505, the method 500 includes accessing the at least one management service of the MnS producer device 300 based on the MnS consumer device type and the obtained authorization. In one embodiment, accessing the at least one management service includes transmitting, by the MnS consumer device 100, an access MnS request to the MnS producer device 300 to access the at least one available management service of the MnS producer device 300. Subsequently, the MnS consumer device 100 may be configured to receive the access MnS response from the MnS producer device 300 to access the at least one available management service of the MnS producer device 300 upon successful verification of the MnS consumer device 100, wherein the MnS producer device 300 verifies the access MnS request based on the OAuth token.

FIG. 6 is a flow diagram illustrating a method 600 for authorizing the at least one management service of the MnS producer device 300, according to an embodiment as disclosed herein. Steps (601 to 604) may be performed by the EGMF device 200.

At step 601, the method 600 includes receiving the on-board API invoker request from the MnS consumer device 100 to register the MnS consumer device 100 with the EGMF device 200, wherein the on-board API invoker request comprises the MnS consumer device type. The on-board API invoker request may indicate that an interested MnS consumer device 100 wishes to access at least one management service provided by the MnS producer device 300.

At step 602, the method 600 includes receiving the publish service API request from the MnS producer device 300, wherein the publish service API request comprises the service API description.

At step 603, the method 600 includes receiving the discover service API request from the MnS consumer device 100 to discover the at least one available management service.

At step 604, the method 600 includes authorizing the MnS consumer device 100 to provide the access to the at least one management service. In one embodiment, authorizing the MnS consumer device 100 includes receiving, by the EGMF device 200, the OAuth2.0 based access token request from the MnS consumer device 100 to authorize the MnS consumer device 100 to access the at least one available management service. In one embodiment, authorizing the MnS consumer device 100 includes verifying, by the EGMF device 200, the received OAuth2.0 based access token request. In one embodiment, authorizing the MnS consumer device 100 includes generating, by the EGMF device 200, the Oauth token based on the MnS consumer device type and the exposure governance control. In one embodiment, authorizing the MnS consumer device 100 includes sending, by the EGMF device 200, the OAuth2.0 based access token response to the MnS consumer device 100, wherein the OAuth2.0 based access token response comprises the generated OAuth token.

FIGS. 7A-7B illustrate a sequence flow diagram illustrating a method 700 for managing service authorization for exposure governance of 5G management capabilities, according to an embodiment as disclosed herein.

Referring to FIG. 7A: At step 701, the MnS consumer device 100 transmits the on-board API invoker request to the EGMF device 200 to register the MnS consumer device 100 with the EGMF device 200, where the on-board API invoker request includes the MnS consumer device type (e.g., OAM internal, OAM external, NOP external, etc.) in APIInvokerEnrolmentDetails, which relates to step 501 of FIG. 5. At step 702, the MnS consumer device 100 receives an on-board API invoker response from the EGMF device 200 upon receiving the on-board API invoker request.

At step 703, the EGMF device 200 receives the publish service API request from the MnS producer device 300, where the publish service API request includes the service API description, which relates to step 602 of FIG. 6, and extensions required for the service API description as shown in Table 2. At step 704, the EGMF device 200 transmits a publish service API response to the MnS producer device 300. Further, the EGMF device 200 develops an intelligence/granular access intelligence based on the MnS consumer device type (exposure details) and other attributes such as the service location, the service availability, the service reliability, and the service latency.

[Table 2]

Furthermore, information associated with the "Type: authorizedMnS" or "authorized MnS DataType", is shown in Table 3.

[Table 3]

At step 705, the MnS consumer device 100 transmits the discover service API request to the EGMF device 200 to discover the at least one available management service at the MnS producer device 300, which relates to step 502 of FIG. 5, where the MnS consumer device 100 discovers the available management services using a CAPIF discovery mechanism. At step 706, the MnS consumer device 100 receives the discover service API response from the EGMF device 200 based on the publish service API request available at the EGMF device 200, where the discover service API response includes the service API description, which relates to step 503 of FIG. 5.

Referring to FIG. 7B: At steps 707 to 714, the MnS consumer device 100 obtains authorization from the EGMF device 200 to access the at least one available management service of the MnS producer device 300. Furthermore, the MnS consumer device 100 establishes a secure session with the MnS producer device 300 to access the at least one available management service. At step 708, the MnS consumer device 100 transmits an OAuth2.0 based access token request to the EGMF device 200, which relates to step 504 of FIG. 5. At step 709, the EGMF device 200 verifies the OAuth2.0 based access token request and generates a token for the MnS consumer device 100, which relates to step 604 of FIG. 6. At step 710, the EGMF device 200 transmits an OAuth2.0 based access token response to the MnS consumer device 100 upon successful verification of the OAuth2.0 based access token request, which relates to step 504 of FIG. 5, where the token (OAuth access token) indicates granular MnS authorization. The granular MnS authorization defines the access of the MnS consumer device 100 to components A, B, and C of the management services defined by 3GPP management service, as defined in 3GPP TS 28.533. Table 4 shows various parameters associated with the token that represents the granular management service access authorization.

[Table 4]

At step 711, the MnS consumer device 100 establishes the secure session with the MnS producer device 300 to access the at least one available management service, which relates to step 505 of FIG. 5. At step 712, the MnS consumer device 100 transmits the access service API request to the MnS producer device 300 to access the at least one available management service of the MnS producer device 300, which relates to step 505 of FIG. 5. At step 713, the MnS producer device 300 checks the validity of the token including checking the granular consumer's authorizations. The MnS producer device 300 will then decide whether to allow access or not. The MnS producer device 300 may interact with the EGMF device 200 (e.g., CAPIF core) for authentication, authorization, and charging. At step 714, the MnS producer device 300 receives the access service API response from the MnS producer device 300 to access the at least one available management service of the MnS producer device 300 upon successful verification of the MnS consumer device 100, which relates to step 505 of FIG. 5, wherein the MnS producer device 300 verifies the access service API request based on the MnS consumer device type, and/or the service API description, and/or the token.

The various actions, acts, blocks, steps, or the like in the flow diagram(s)/ sequence diagram(s) may be performed in the order presented, in a different order, or simultaneously. Further, in some embodiments, some of the actions, acts, blocks, steps, or the like may be omitted, added, modified, skipped, or the like without departing from the scope of the disclosure.

Unlike existing methods and systems, the disclosed method(s) and system provide (a) extensions to the service API description to describe management services to be exposed to the 3^rd parties/MnS consumer device 100, (b) the OAuth access token for exposure governance control IOC. The OAuth access token will be created representing the granular MnS authorization of the MnS consumer device 100. As a result, the 3^rd parties/MnS consumer device 100 (e.g., vertical/external customer) access the at least one management service, exposed by the MnS producer device 300 (e.g., the 3GPP management system), by utilizing the EGMF device 200 (e.g., CAPIF framework). Furthermore, the proposed method and system allow to access the at least one management service based on the MnS consumer device type and its contract with an operator(s). This avoids exposing the entire set of management capabilities to the 3^rd parties /MnS consumer devices 100.

Unlike existing methods and systems, the disclosed method(s) and system provide a Possible solution for network slice management capability exposure. The solution proposes to use the CAPIF framework to expose network slice management capabilities to external entities (e.g., 3rd parties/MnS consumer device(s) 100). The solution requires extending the existing CAPIF mechanism to support MnS exposure and authorization. This includes extending the ServiceAPIDescription to support the description of the 3GPP management services required for exposure. The disclosed method and system include defining a mechanism to build exposure governance rules for allowing granular access to the MnS from the external entities. In addition to the external entities, the same solution can be used to provide access to entities inside the PLMN trust domain.

FIG. 8 illustrates an electronic device according to embodiments of the disclosure.

Referring to the FIG. 8, the electronic device 800 may include a processor 810, a transceiver 820 and a memory 830. However, all of the illustrated components are not essential. The electronic device 800 may be implemented by more or less components than those illustrated in FIG. 8. In addition, the processor 810 and the transceiver 820 and the memory 830 may be implemented as a single chip according to another embodiment.

The electronic device 800 may correspond to the device (100, 200, 300) described above.

The aforementioned components will now be described in detail.

The processor 810 may include one or more processors or other processing devices that control the proposed function, process, and/or method. Operation of the electronic device 800 may be implemented by the processor 810.

The transceiver 820 may include a RF transmitter for up-converting and amplifying a transmitted signal, and a RF receiver for down-converting a frequency of a received signal. However, according to another embodiment, the transceiver 820 may be implemented by more or less components than those illustrated in components.

The transceiver 820 may be connected to the processor 810 and transmit and/or receive a signal. The signal may include control information and data. In addition, the transceiver 820 may receive the signal through a wireless channel and output the signal to the processor 810. The transceiver 820 may transmit a signal output from the processor 810 through the wireless channel.

The memory 830 may store the control information or the data included in a signal obtained by the electronic device 800. The memory 830 may be connected to the processor 810 and store at least one instruction or a protocol or a parameter for the proposed function, process, and/or method. The memory 830 may include read-only memory (ROM) and/or random access memory (RAM) and/or hard disk and/or CD-ROM and/or DVD and/or other storage devices.

FIG. 9 illustrates a base station according to embodiments of the disclosure.

Referring to the FIG. 9, the base station 900 may include a processor 910, a transceiver 920 and a memory 930. However, all of the illustrated components are not essential. The base station 900 may be implemented by more or less components than those illustrated in FIG. 9. In addition, the processor 910 and the transceiver 920 and the memory 930 may be implemented as a single chip according to another embodiment.

The base station 900 may correspond to the system (101, 201) described above.

The aforementioned components will now be described in detail.

The processor 910 may include one or more processors or other processing devices that control the proposed function, process, and/or method. Operation of the base station 900 may be implemented by the processor 910.

The transceiver 920 may include a RF transmitter for up-converting and amplifying a transmitted signal, and a RF receiver for down-converting a frequency of a received signal. However, according to another embodiment, the transceiver 920 may be implemented by more or less components than those illustrated in components.

The transceiver 920 may be connected to the processor 910 and transmit and/or receive a signal. The signal may include control information and data. In addition, the transceiver 920 may receive the signal through a wireless channel and output the signal to the processor 910. The transceiver 920 may transmit a signal output from the processor 910 through the wireless channel.

The memory 930 may store the control information or the data included in a signal obtained by the base station 900. The memory 930 may be connected to the processor 910 and store at least one instruction or a protocol or a parameter for the proposed function, process, and/or method. The memory 930 may include read-only memory (ROM) and/or random access memory (RAM) and/or hard disk and/or CD-ROM and/or DVD and/or other storage devices.

Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one ordinary skilled in the art to which this disclosure belongs. The system, methods, and examples provided herein are illustrative only and not intended to be limiting.

While specific language has been used to describe the present subject matter, any limitations arising on account thereto, are not intended. As would be apparent to a person in the art, various working modifications may be made to the method to implement the inventive concept as taught herein. The drawings and the forgoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment.

The embodiments disclosed herein can be implemented using at least one hardware device and performing network management functions to control the elements.

The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the scope of the embodiments as described herein.

Claims

A method (500) for accessing at least one management service of a management services (MnS) producer device (300) by an MnS consumer device (100), the method comprising:

transmitting (501), by an MnS consumer device (100), an on-board application programming interface (API) invoker request to an exposure governance management function (EGMF) device (200) to register the MnS consumer device (100) with the EGMF device (200), wherein the on-board API invoker request comprises an MnS consumer device type;

transmitting (502), by the MnS consumer device (100), a discover service API request to the EGMF device (200) to discover the at least one available management service;

receiving (503), by the MnS consumer device (100), a discover service API response from the EGMF device (200) based on a published service API available at the EGMF device (200), wherein the discover service API response comprises a service API description describing the at least one available management service;

obtaining (504), by the MnS consumer device (100), authorization from the EGMF device (200) to access the at least one available management service; and

accessing (505), by the MnS consumer device (100), the at least one management service of the MnS producer device (300) based on the MnS consumer device type and the obtained authorization.
The method (500) of claim 1, wherein obtaining (504) authorization from the EGMF device (200) comprises:

transmitting, by the MnS consumer device (100), an open authorization version 2 (OAuth2.0) based access token request to the EGMF device (200) to obtain authorization from the EGMF device (200) to access the at least one available management service; and

receiving, by the MnS consumer device (100), an OAuth2.0 based access token response from the EGMF device (200), wherein the OAuth2.0 access token response comprises an OAuth token, and the Oauth token is generated by the EGMF device (200) based on the MnS consumer device type and an exposure governance intelligence.
The method (500) of claim 1, wherein accessing (505) the at least one management service comprises:

transmitting, by the MnS consumer device (100), an access MnS request to the MnS producer device (300) to access the at least one available management service of the MnS producer device (300); and

receiving, by the MnS consumer device (100), an access MnS response from the MnS producer device (300) to access the at least one available management service of the MnS producer device (300) upon successful verification of the MnS consumer device (100), wherein the MnS producer device (300) verifies the access MnS request based on an OAuth token.
The method (500) of claim 1, wherein the MnS consumer device type comprises a network operator (NOP) external MnS consumer device (100), Operation and Maintenance (OAM) external MnS consumer device (100), and an OAM internal MnS consumer device (100).
The method (500) of claim 4, wherein the NOP external MnS consumer device (100) is external to a public land mobile network (PLMN) trust domain, the OAM external MnS consumer device (100) is external to a 3rd generation partnership project (3GPP) management domain, and the OAM internal MnS consumer device (100) is internal to the 3GPP management domain.
The method (500) of claim 1, wherein the service API description comprises an exposer detail for each type of the MnS consumer device (100), a service location, a service availability, a service reliability, and a service latency.
A method (600) for authorizing at least one management service of a management services (MnS) producer device (300) by an exposure governance management function (EGMF) device (200), the method comprising:

receiving (601), by the EGMF device (200), an on-board application programming interface (API) invoker request from an MnS consumer device (100) to register the MnS consumer device (100) with the EGMF device (200), wherein the on-board API invoker request comprises an MnS consumer device type;

receiving (602), by the EGMF device (200), a publish service API request from the MnS producer device (300), wherein the publish service API request comprises a service API description;

receiving (603), by the EGMF device (200), a discover service API request from the MnS consumer device (100) to discover the at least one available management service; and

authorizing (604), by the EGMF device (200), the MnS consumer device (100) to provide an access to the at least one management service.
The method (600) of claim 7, wherein authorizing (604) the MnS consumer device (100) comprises:

receiving, by the EGMF device (200), an open authorization version 2 (OAuth2.0) based access token request from the MnS consumer device (100) to authorize the MnS consumer device (100) to access the at least one available management service;

verifying, by the EGMF device (200), the received OAuth2.0 based access token request;

generating, by the EGMF device (200), an Oauth token based on the MnS consumer device type and an exposure governance intelligence; and

sending, by the EGMF device (200), an OAuth2.0 based access token response to the MnS consumer device (100), wherein the OAuth2.0 based access token response comprises the generated OAuth token.
A system (101) for authorizing a management services (MnS) consumer device to access at least one management service of an MnS producer device (300), the system (101) comprising:

a memory (110);

a processor (120);

a communicator (130); and

an MnS access module (140), operably coupled with the memory (110), the processor (120), and the communicator (130), configured to:

transmit an on-board API invoker request to an exposure governance management function (EGMF) device (200) to register the MnS consumer device (100) with the EGMF device (200), wherein the on-board application programming interface (API) invoker request comprises an MnS consumer device type;

transmit a discover service API request to the EGMF device (200) to discover the at least one available management service;

receive a discover service API response from the EGMF device (200) based on a published service API available at the EGMF device (200), wherein the discover service API response comprises a service API description describing the at least one available management service;

obtain authorization from the EGMF device (200) to access the at least one available management service; and

access the at least one management service of the MnS producer device (300) based on the MnS consumer device type and the obtained authorization.
The system (101) of claim 9, wherein to obtain authorization from the EGMF device (200), the MnS access module (140) is configured to:

transmit an open authorization version 2 (Oauth2.0) based access token request to the EGMF device (200) to obtain authorization from the EGMF device (200) to access the at least one available management service; and

receive an Oauth2.0 based access token response from the EGMF device (200), wherein the Oauth2.0 access token response comprises an Oauth token, and the Oauth token is generated by the EGMF device (200) based on the MnS consumer device type and an exposure governance intelligence.
The system (101) of claim 9, wherein to access the at least one management service, the MnS access module (140) is configured to:

transmit an access MnS request to the MnS producer device (300) to access the at least one available management service of the MnS producer device (300); and

receive an access MnS response from the MnS producer device (300) to access the at least one available management service of the MnS producer device (300) upon successful verification of the MnS consumer device (100), wherein the MnS producer device (300) verifies the access MnS request based on an OAuth token.
The system (101) of claim 9, wherein the MnS consumer device type comprises a network operator (NOP) external MnS consumer device (100), operation and maintenance (OAM) external MnS consumer device (100), and an OAM internal MnS consumer device (100).
The system (101) of claim 12, wherein the NOP external MnS consumer device (100) is external to a public land mobile network (PLMN) trust domain, the OAM external MnS consumer device (100) is external to a 3rd generation partnership project (3GPP) management domain, and the OAM internal MnS consumer device (100) is internal to the 3GPP management domain.
The system (101) of claim 9, wherein the service API description comprises an exposer detail for each type of the MnS consumer device (100), a service location, a service availability, a service reliability, and a service latency.
A system (201) for authorizing at least one management service of a management services (MnS) producer device (300) by an exposure governance management function (EGMF) device (200), the system (201) comprising:

a memory (210);

a processor (220);

a communicator (230); and

an MnS access module (240), operably coupled with the memory (210), the processor (220), and the communicator (230), configured to:

receive an on-board application programming interface (API) invoker request from an MnS consumer device (100) to register the MnS consumer device (100) with the EGMF device (200), wherein the on-board API invoker request comprises an MnS consumer device type;

receive a publish service API request from the MnS producer device (300), wherein the publish service API request comprises a service API description;

receive a discover service API request from the MnS consumer device (100) to discover the at least one available management service; and

authorize the MnS consumer device (100) to provide an access to the at least one management service.