WO2022128131A1

WO2022128131A1 - Providing vendor-specific information in 5gc

Info

Publication number: WO2022128131A1
Application number: PCT/EP2020/087243
Authority: WO
Inventors: Meenakshi Sundaram G; Robert TÖRNKVIST; R Kumar; A. K Diwahar
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2020-12-18
Filing date: 2020-12-18
Publication date: 2022-06-23

Abstract

The present disclosure relates to methods of enabling providing of vendor-specific information in a core network of a fifth generation data communication network, and devices performing the methods. In an aspect, a method of a network function (NF, 30) enabling providing of vendor-specific information in a core network of a 5G data communication network. The method comprising acquiring (S101) the vendor-specific information, storing (S102) the acquired vendor-specific information, and providing (S103) the stored vendor-specific information to a requesting NF (22).

Description

PROVIDING VENDOR-SPECIFIC INFORMATION IN 5GC

TECHNICAL FIELD

[0001] The present disclosure relates to methods of enabling providing of vendorspecific information in a core network of a fifth generation data communication network, and devices performing the methods.

BACKGROUND

[0002] In 5^th generation (5G) data communication systems, great bandwidth and thus high download speeds are provided and it is therefore expected that the new 5G systems not only will serve mainly mobile terminals but will also be used as general internet service provider (ISP) systems for laptops and desktop computers, thereby competing with existing ISP technologies such as cable internet.

[0003] A challenge with 5G data communication systems is that various network functions (NFs) may require access to vendor-specific information, but there is currently no mechanism to provide such information in the systems.

SUMMARY

[0004] An objective is to solve, or at least mitigate, this problem in the art and thus to provide a method of enabling providing of vendor-specific information in a core network of a 5G data communication network.

[0005] This objective is attained in a first aspect by a method of an NF enabling providing of vendor-specific information in a core network of a 5G data communication network. The method comprises acquiring the vendor-specific information, storing the acquired vendor-specific information, and providing the stored vendor-specific information to a requesting NF.

[0006] This objective is attained in a second aspect by an NF configured to enable providing of vendor-specific information in a core network of a 5G data communication network, the NF comprising a processing unit and a memory, said memory containing instructions executable by said processing unit, whereby the NF is operative to acquire the vendor-specific information, store the acquired vendorspecific information, and provide the stored vendor-specific information to a requesting NF. [0007] This objective is attained in a third aspect by a method of a provider NF enabling providing of vendor-specific information in a core network of a 5G data communication network. The method comprising acquiring the vendor-specific information from an NF configured to store the vendor-specific information, receiving a request from a consumer NF of a vendor associated with the vendorspecific information, performing provider NF-specific processing of information based on the acquired vendor-specific information in response to the received request, and sending the processed information to said consumer NF.

[0008] This objective is attained in a fourth aspect by a provider NF configured to enable providing of vendor-specific information in a core network of a 5G data communication network, the NF comprising a processing unit and a memory, said memory containing instructions executable by said processing unit, whereby the NF is operative to acquire the vendor-specific information from an NF configured to store the vendor-specific information, receive a request from a consumer NF of a vendor associated with the vendor-specific information, performing provider NF- specific processing of information based on the acquired vendor-specific information in response to the received request, and send the processed information to said consumer NF.

[0009] Thus, vendors will via an appropriate NF register vendor-specific information in such as vendor ID, charging rate for the vendor, expected Quality of Service (QoS), etc., with an NF referred to as an Object Repository Function (ORF) which stores the vendor-specific information. The ORF may be a stand-alone entity or implemented within a suitable NF. Any NF wishing to access the vendor information will thus send a request for one or more sets of vendor information held in the ORF which will provide the requested vendor information accordingly

[0010] Advantageously, the ORF is introduced in the 5G core network architecture to store the vendor information and to make the stored vendor information available to NFs requesting the information.

[0011] In an embodiment, the ORF acquires the vendor-specific information from an NF of the vendor. [0012] In an embodiment, the storing of the acquired vendor-specific information comprises storing new vendor-specific information or updating already stored vendor-specific information.

[0013] In an embodiment, the ORF receives a request for the stored vendorspecific information from the requesting NF and sends the stored vendor-specific information to the requesting NF.

[0014] In an embodiment, the ORF receives a subscription request from the requesting NF to obtain vendor-specific information and sends the vendor-specific information indicated with the subscription request to the requesting NF.

[0015] In an embodiment, the requesting NF receives, from a vendor associated with vendor-specific information, an indication of the location of the vendor-specific information in the 5G data communication network, sends a request to obtain the vendor-specific information to the indicated location and receives the requested vendor-specific information from the indicated location.

[0016] In an embodiment, the requesting NF sends a subscription request to the NF configured to store the vendor-specific information and receives the vendorspecific information indicated with the subscription request.

[0017] In an embodiment, the requesting NF configures other NFs with the received vendor-specific information.

[0018] Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a/an/the element, apparatus, component, means, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Aspects and embodiments are now described, by way of example, with reference to the accompanying drawings, in which:

[0020] Figure 1 shows a 5G data communication network in which embodiments may be implemented; [0021] Figure 2 illustrates a number of Network Functions communicating with a

Charging Function;

[0022] Figure 3 illustrates an Object Repository Function according to an embodiment;

[0023] Figure 4 illustrates the Object Repository Function being implemented in a Network Function Repository Function according to an embodiment;

[0024] Figure 5 shows a flowchart illustrating a method of enabling providing vendor-specific information to a Network Function according to an embodiment;

[0025] Figure 6 shows a flowchart illustrating a method of enabling providing vendor-specific information to a Network Function according to another embodiment;

[0026] Figure 7 illustrates a register Network Function according to an embodiment; and

[0027] Figure 8 illustrates a provider Network Function according to an embodiment.

DETAILED DESCRIPTION

[0028] The aspects of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the invention are shown.

[0029] These aspects may, however, be embodied in many different forms and should not be construed as limiting; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and to fully convey the scope of all aspects of invention to those skilled in the art. Like numbers refer to like elements throughout the description.

[0030] Figure 1 illustrates a core network of a 5G telecommunication system being connected to a Radio Access Network (RAN) 12 and a wireless communications device 11 referred to as a User Equipment (UE), and further being connected to a data network 13 such as the Internet. Commonly, the core network in a 5G telecommunication system is referred to as 5GC. Embodiments may be implemented in such a core network as will be discussed. [0031] The 5GC comprises a number of entities referred to as Network Functions (NFs) which will be described in the following. A User Plane Function (UPF) 10 is a service function that processes user plane packets; processing may include altering the packet’s payload and/or header, interconnection to data network(s), packet routing and forwarding, etc. The UPF 10 may in practice be decomposed into many small UPFs referred to as pUPFs.

[0032] Further, the 5GC comprises a Network Exposure Function (NEF) 14 for exposing capabilities and events, an NF (Network Function) Repository Function (NRF) 15 for providing discovery and registration functionality for NFs, a Policy Control Function (PCF) 16, Unified Data Management (UDM) 17 for storing subscriber data and profiles, and an Application Function (AF) 18 for supporting application influence on traffic routing.

[0033] Moreover, the 5GC comprises an Authentication Server Function (AUSF) 19 storing data for authentication of the UE 11, an Access and Mobility Function (AMF) 20 for providing UE-based authentication, authorization, mobility management, etc., and a Session Management Function (SMF) 21 configured to perform session management, e.g. session establishment, modify and release, etc.

[0034] The NRF 15 supports the following functionality:

- maintains NF profiles of available NF instances and their supported services;

- maintains Service Communication Proxy (SCP) profiles of available SCP instances;

- allows other NF or SCP instances to subscribe to, and be notified about, the registration in NRF of new NF instances of a given type. The NRF 15 also allows SCP instances to subscribe to, and be notified about, the registration in NRF of new SCP instances;

- service discovery; the NRF 15 receives NF Discovery Requests from NF or SCP instances, and provides the information of the available NF instances fulfilling certain criteria (e.g., supporting a given service);

- SCP discovery; the NRF 15 receives NF Discovery Requests for SCP profiles from other SCP instances and provides the information of the available SCP instances fulfilling certain criteria (e.g., serving a given NF set). [0035] Figure 2 illustrates a number of NFs - in this example the SMF 21, the AMF 20 and the NEF 14 - communicating with a Charging Function (CHF) 22 via a so-called Nchf interface. As the name implies, the CHF 22 manages charging activities for the services provided in the system, for instance credit control, accounting, billing, statistics, etc.

[0036] When offline charging and online charging are applicable to a service delivery, the charging information of both offline charging and online charging can be provided in a single command; this is referred to as converged charging.

[0037] An NF such as the SMF 21 shall be able to perform convergent charging by interacting with CHF 22 for charging data related to packet data unit (PDU) sessions. Typically, Charging Data Requests and Charging Data Responses are exchanged between the SMF 21 and the CHF 22 at initiative of the SMF 21 when certain chargeable events occur. The CHF 22 generates and stores Charging Data Records (CDRs) for the services to be charged.

[0038] A problem with the 5GC is that currently there are no provisions for adding vendor-specific information to messages sent between NFs, such as between the SMF 21 and the CHF 22. For instance, the vendor-specific information may identify a particular vendor and any information associated with the vendor such as an individual charging rate, or other information affecting a standard charging rate based on a vendor-specific parameter, a particular equipment being used, a certain Quality of Service (QoS) having been agreed upon, etc.

[0039] In an embodiment, a stand-alone vendor information storage is introduced referred to as an Object Repository Function (ORF). The ORF is also referred to as a register NF.

[0040] Figure 3 schematically illustrates existing NFs associated with corresponding vendors according to an embodiment. In this particular example the NFs are embodied in the form of SMFs. Hence, a first SMF 21a is associated with vendor 1, while a second SMF 21b is associated with vendor 2 and a third SMF 21c is associated with vendor 3. These NFs are referred to as consumer NFs.

[0041] Each SMF 2ia-2ic will thus register vendor-specific information in step S101, such as vendor ID, charging rate for the vendor, expected Quality of Service (QoS), etc., with the ORF 30 which stores the vendor-specific information in step S102. Any NF wishing to access the vendor information, for instance the CHF 22 (referred to as a provider NF), will thus send a request for one or more sets of vendor information held in the ORF 30 which will provide the requested vendor information to the CHF 22 in step S103. In other words, the ORF 30 acquires the vendor-specific information from each SMF 2ia-2ic in step S101 either by actively requesting the vendor-specific information from the SMFs 2ia-2ic or by receiving the vendorspecific information from the SMFs 2ia-2ic for instance in connection to the SMFs 2ia-2ic making a registration request in step S101 with the ORF 30.

[0042] The ORF 30 may be configured with a so-called Service Based Interface (SBI) for communicating with the various NFs.

[0043] Advantageously, the ORF 30 is introduced in the 5GC architecture to store the vendor information and to make the stored vendor information available to NFs requesting the information. The vendor information may be used for instance by the CHF 22 when performing converged charging for taking into account vendor specifics.

[0044] A further advantage in deploying a centralized stand-alone ORF 30 in the 5GC is that any NF may access the ORF 30 via the SBI and there is thus no need for NFs to turn to a plurality of repository for accessing the vendor information of a particular vendor. Vendor information maybe coordinated between NFs within a Public Land Mobile Network (PLMN) or across PLMNs.

[0045] Further, the NFs may advantageously subscribe to vendor information at the ORF 30, even with particular requirements (“Information A, Vendor 1”) or if vendor information associated with a particular vendor is updated, which avoids the major effort of manually configurating multiple NFs.

[0046] In an embodiment, any requested vendor information stored at the ORF 30 is included in a header of the message sent from the ORF 30 to the requesting NF.

[0047] In another embodiment, the ORF 30 is not implemented as a stand-alone unit, but is included in and thus co-located with an appropriate NF such as the NRF 15.

[0048] Figure 4 illustrates the ORF 30 being implemented in the NFR 15 according to an embodiment along with other NRF functionality such as NF Management 15a, NF Subscription 15b and NF Discovery 15c. It may alternatively be envisaged that the ORF 30 is implemented within an Operations Support System (OSS) or Operations & Maintenance (O&M) unit of the 5G telecommunication system.

[0049] The NRF 15 provides the following services to other NFs:

• Nnrf_NFManagement - allows an NF to register, update or deregister its profile in the NRF and also to subscribe to be notified of newly registered NFs along with their NF services;

• Nnrf_NFDiscovery - allows an NF to discover services offered by other

NFs by querying the local NRF;

• Nnrf_AccessToken - allows 0Auth2 Authorization of an NF; and

• Nnrf_Bootstrapping - allows NF service consumers to know which service endpoints the NRF supports.

[0050] Further, in this embodiment, where the ORF 30 is implemented in the NRF 15, a further service is provided to other NFs:

• Nnrf_ObjectStoreManagement, which allows NFs to acquire vendor information from the NRF 15 stored in the ORF 30. The NFs may subscribe to the vendor information held in the ORF 30. The NRF 15 may be configured with a new application programming interface (API) via which the vendor information service is provided.

[0051] Figure 5 shows a flowchart illustrating a method of enabling providing vendor-specific information to an NF according to an embodiment. Initially, authorization/authentication is performed using existing mechanisms.

[0052] In step S201, an NF of this particular vendor 31, such as SMF 21a will thus register vendor-specific information at the NRF 15, e.g. vendor ID, charging rate for the vendor, expected QoS, etc. This may either be registered at the NRF 15 as a new vendor information item or an already available vendor information item is updated with new data.

[0053] The NRF 15 will thus receive the vendor-specific information and store the information, or update an existing vendor-specific information item, in step S202. [0054] This registering may be followed by a confirmation in step S203 that the vendor information has been successfully registered at the NRF 15.

[0055] The vendor 31 notifies the CHF 22 in step S204 that vendor-specific information has been registered with the NRF 15. The notification may include an identifier of the particular set of vendor information registered in step S201, since the NRF 15 may hold a large database of sets of vendor information. Further, the notification may include a destination address to the holder of the vendor information, in this particular example being NRF 15, e.g. in the form of a Uniform Resource Locator (URL). The CHF 22 confirms in step S205 that the notification has been received.

[0056] In step S206, the CHF 22 makes a request to the NRF 15 for the vendor information indicated by the vendor 31 in step S204, and the NRF 15 responds by sending the requested vendor information to the CHF 22 in step S207. The CHF 22 stores the received vendor information in step S208.

[0057] The SMF 21a sends a charging request to the CHF 22 in step S209, and the CHF 22 may generate a charging data record (CDR) accordingly in step S210 to be provided to a billing system, based on the vendor information. For instance, the CHF 22 may perform charging by concluding that a certain amount of data has been consumed by the vendor 31 and further from the acquired vendor information that this particular vendor should be charged a predetermined rate, e.g. as agreed upon in a service level agreement (SLA) for the given amount of consumed data.

[0058] In other words, the CHF 22 performs NF-specific processing of information based on the vendor information in step S210, which in the case of the CHF includes performing charging processing.

[0059] The CHF 22 may respond to the charging request by sending a charging response to the SMF 21a in step S211 for instance comprising an authorization granting the SMF 21a (and thus the vendor 31) access to a particular service and possibly to which extent the service can be used in terms of e.g. number of “charging units” to be spent for the service. Further, the vendor information acquired in step S207 maybe included in the response in S211. Hence, the processed information of step S210 is sent to the SMF 21a in step S211. [0060] Figure 6 shows a flowchart illustrating a method of enabling providing of vendor-specific information to an NF according to another embodiment. Initially, authorization/authentication is performed using existing mechanisms.

[0061] In step S301, the CHF 22 sends a subscription request to the NRF 15 for vendor information. This request may indicate subscription to vendor information from one or more particular vendors, for vendor information associated with a particular service, or a particular type of vendor information, etc.

[0062] The NRF 15 may respond in step S302 with a confirmation that the subscription request has been successfully received.

[0063] An NF of the vendor, such as SMF 21a, will register vendor-specific information at the NRF 15, e.g. vendor ID, charging rate for the vendor, expected QoS, etc., in step S303. This may either be registered at the NRF 15 as a new vendor information item or an already available vendor information item is updated with new data.

[0064] The NRF 15 will thus receive the vendor-specific information and store the information, or update an existing vendor-specific information item, in step S304.

[0065] This registering may be followed by a confirmation in step S305 that the vendor information has been successfully registered at the NRF 15. It is noted that steps S301 and S302 alternatively maybe performed after steps S303-S305.

[0066] The NRF 15 sends the vendor-specific information to CHF 22 in step S306, as requested by the CHF 22 in step S301 with the subscription request. The CHF 22 stores the received vendor information in step S307 for later use, and may further confirm in step S308 that the vendor information has been received.

[0067] Further optional is that the CHF 22 may configure NFs in the 5GC to use the received vendor information; the CHF 22 may send the vendor-specific information to any NF requiring the information in the 5GC in step S309.

[0068] The SMF 21a sends a charging request to the CHF 22 in step S310, and the CHF 22 generates a CDR accordingly in step S311. For instance, the CHF 22 concludes that a certain amount of data has been consumed by the vendor 31 and further from the acquired vendor information that this particular vendor should be charged a predetermined rate, e.g. as agreed upon in an SLA for the given amount of consumed data. [0069] The CHF 22 responds (cf. step S211) to the charging request by sending a charging response to the SMF 21a in step S312. Advantageously, with this embodiment, there is no need for the vendor to communicate with the CHF 22. Instead, the CHF 22 subscribes to the vendor information, and the NRF 15 accordingly sends any newly registered or updated vendor information to the CHF 22.

[0070] Figure 7 illustrates an NF in the form of the ORF 30 enabling providing of vendor-specific information in a core network of a 5G data communication network according to an embodiment. The steps of the method performed by the ORF 30 are in practice performed by a processing unit 101 embodied in the form of one or more microprocessors arranged to execute a computer program 102 downloaded to a suitable storage volatile medium 103 associated with the microprocessor, such as a Random Access Memory (RAM), or a non-volatile storage medium such as a Flash memory or a hard disk drive. The processing unit 101 is arranged to cause the ORF 30 to carry out the method according to embodiments described herein, when the appropriate computer program 102 comprising computer-executable instructions is downloaded to the storage medium 103 and executed by the processing unit 101. The storage medium 103 may also be a computer program product comprising the computer program 102. Alternatively, the computer program 102 maybe transferred to the storage medium 103 by means of a suitable computer program product, such as a Digital Versatile Disc (DVD) or a memory stick. As a further alternative, the computer program 102 maybe downloaded to the storage medium 103 over a network. The processing unit 101 may alternatively be embodied in the form of a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), etc. The ORF 39 further comprises a wired or wireless interface 104 over which data may be received and transmitted.

[0071] Figure 8 illustrates an NF in the form of the CHF 22 enabling providing of vendor-specific information in a core network of a 5G data communication network according to an embodiment. The steps of the method performed by the CHF 22 are in practice performed by a processing unit 111 embodied in the form of one or more microprocessors arranged to execute a computer program 112 downloaded to a suitable storage volatile medium 113 associated with the microprocessor, such as a RAM, or a non-volatile storage medium such as a Flash memory or a hard disk drive. The processing unit ill is arranged to cause the CHF 22 to carry out the method according to embodiments described herein, when the appropriate computer program 112 comprising computer-executable instructions is downloaded to the storage medium 113 and executed by the processing unit 111. The storage medium 113 may also be a computer program product comprising the computer program 112. Alternatively, the computer program 112 maybe transferred to the storage medium 113 by means of a suitable computer program product, such as a DVD or a memory stick. As a further alternative, the computer program 112 may be downloaded to the storage medium 113 over a network. The processing unit 111 may alternatively be embodied in the form of a DSP, an ASIC, an FPGA, a CPLD, etc. The CHF 22 further comprises a wired or wireless interface 114 over which data may be received and transmitted.

[0072] The NF of Figure 7 and/ or Figure 8 may be provided as a standalone device or as a part of at least one further device. For example, the NF maybe provided in a node of the core network. Alternatively, functionality of the NF may be distributed between at least two devices, or nodes. These at least two nodes, or devices, may either be part of the same network part (such as the core network) or may be spread between at least two such network parts. In general terms, instructions that are required to be performed in real time may be performed in a device, or node, operatively closer to a radio cell than instructions that are not required to be performed in real time.

[0073] Thus, a first portion of the instructions performed by the NF may be executed in a first device, and a second portion of the of the instructions performed by the NF may be executed in a second device; the herein disclosed embodiments are not limited to any particular number of devices on which the instructions performed by the NF may be executed.

[0074] Hence, the methods according to the herein disclosed embodiments are suitable to be performed by an NF residing in a cloud computational environment. Therefore, although a single processing circuitry 101/111 is illustrated in Figure 7 and Figure 8 the processing circuitry 101/111 maybe distributed among a plurality of devices, or nodes. The same applies to the computer program 102/ 112. [0075] The aspects of the present disclosure have mainly been described above with reference to a few embodiments and examples thereof. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims.

[0076] Thus, while various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims.

Claims

1. A method of a network function (30), NF, enabling providing of vendor-specific information in a core network of a fifth generation, 5G, data communication network, comprising: acquiring (S101) the vendor-specific information; storing (S102) the acquired vendor-specific information; and providing (S103) the stored vendor-specific information to a requesting NF (22).

2. The method of claim 1, the acquiring (S101) of the vendor-specific information comprising: acquiring the vendor-specific information from an NF (21a) of the vendor.

3. The method of any one of claims 1 or 2, the storing (S102) of the acquired vendor-specific information comprising storing new vendor-specific information or updating already stored vendor-specific information.

4. The method of any one of the preceding claims, the providing of the stored vendor-specific information to a requesting NF (22) comprises: receiving (S206) a request for the stored vendor-specific information from the requesting NF (22); and sending (S207) the stored vendor-specific information to the requesting NF (22).

5. The method of any one of the preceding claims, the providing of the stored vendor-specific information to a requesting NF (22) comprises: receiving (S301) a subscription request from the requesting NF (22) to obtain vendor-specific information; and sending (S306) the vendor-specific information indicated with the subscription request to the requesting NF (22).

6. A method of a provider network function (22), NF, enabling providing of vendor-specific information in a core network of a fifth generation, 5G, data communication network, comprising: acquiring (S207) the vendor-specific information from an NF (15) configured to store the vendor-specific information; receiving (S209) a request from a consumer NF (21a) of a vendor associated with the vendor-specific information; performing (S210) provider NF-specific processing of information based on the acquired vendor-specific information in response to the received request; and sending (S211) the processed information to said consumer NF (21a).

7. The method of claim 6, the acquiring of the vendor-specific information from an NF (15) configured to store the vendor-specific information comprises: receiving (S204), from a vendor (31) associated with vendor-specific information, an indication of the location of the vendor-specific information in the 5G data communication network; sending (S206) a request to obtain the vendor-specific information to the indicated location; and receiving (S207) the requested vendor-specific information from the indicated location.

8. The method of claim 6, the providing of the stored vendor-specific information to a requesting NF (22) comprises: sending (S301) a subscription request to the NF (15) configured to store the vendor-specific information; and receiving (S306) the vendor-specific information indicated with the subscription request.

9. The method of claim 8, further comprising: configuring (S309) other NFs with the received vendor-specific information.

10. A computer program (102) comprising computer-executable instructions for causing a network function (30) to perform steps recited in any one of claims 1-5 when the computer-executable instructions are executed on a processing unit (101) included in the network function (30).

11. A computer program product comprising a computer readable medium (103), the computer readable medium having the computer program (102) according to claim 10 embodied thereon.

12. A computer program (112) comprising computer-executable instructions for causing a network function (22) to perform steps recited in any one of claims 6-9 when the computer-executable instructions are executed on a processing unit (111) included in the network function (22). 16

13. A computer program product comprising a computer readable medium (123), the computer readable medium having the computer program (122) according to claim 12 embodied thereon.

14. A network function (30), NF, configured to enable providing of vendor-specific information in a core network of a fifth generation, 5G, data communication network, the NF (30) comprising a processing unit (101) and a memory (103), said memory containing instructions (102) executable by said processing unit (101), whereby the NF (30) is operative to: acquire the vendor-specific information; store the acquired vendor-specific information; and provide the stored vendor-specific information to a requesting NF (22), NF.

15. The NF (30) of claim 14, being operative to, when acquiring the vendor-specific information: acquire the vendor-specific information from an NF (21a) of the vendor.

16. The NF (30) of any one of claims 14 or 15, being operative to, when storing the acquired vendor-specific information: store new vendor-specific information or update already stored vendor-specific information.

17. The NF (30) of any one of claims 14-16, being operative to, when providing the stored vendor-specific information to a requesting NF (22): receive a request for the stored vendor-specific information from the requesting NF (22); and send the stored vendor-specific information to the requesting NF (22).

18. The NF (30) of any one of claims 14-17, being operative to, when providing the stored vendor-specific information to a requesting NF (22): receive a subscription request from the requesting NF (22) to obtain vendorspecific information; and send the vendor-specific information indicated with the subscription request to the requesting NF (22).

19. A provider network function (22), NF, configured to enable providing of vendor-specific information in a core network of a fifth generation, 5G, data communication network, the NF (22) comprising a processing unit (111) and a 17 memory (113), said memory containing instructions (112) executable by said processing unit (111), whereby the NF (22) is operative to: acquire the vendor-specific information from an NF (15) configured to store the vendor-specific information; receive a request from a consumer NF (21a) of a vendor associated with the vendor-specific information; perform provider NF-specific processing of information based on the acquired vendor-specific information in response to the received request; and send the processed information to said consumer NF (21a).

20. The NF (22) of claim 19, being operative to, when acquiring the vendor-specific information from an NF (15) configured to store the vendor-specific information: receive, from a vendor (31) associated with vendor-specific information, an indication of the location of the vendor-specific information in the 5G data communication network; send a request to obtain the vendor-specific information to the indicated location; and receive the requested vendor-specific information from the indicated location.

21. The NF (22) of claim 19, being operative to, when providing the stored vendorspecific information to a requesting NF (22): send a subscription request to the NF (15) configured to store the vendorspecific information; and receive the vendor-specific information indicated with the subscription request.

22. The NF (22) of claim 21, further being operative to: configure other NFs with the received vendor-specific information.