Technical Field

The present disclosure generally relates to the field of data storage and retrieval. In particular, a technique for handling vendor specific data in a system comprising a common data repository requiring a common request format standardized among a plurality of vendors is presented. The technique may be embodied in methods, computer programs, apparatuses and systems.

Background

Mobile communication systems of the fifth generation (5G) generally make use of the so-called Service Based Architecture (SBA) in which, rather than using the traditional peer-to-peer interfaces and protocols, each Network Function (NF) may provide - as a "producer" - one or more "services" to one or more "consumers", e.g., using the Hypertext Transfer Protocol (HTTP)/Representational State Transfer (REST).

As a new NF, 5G mobile communication systems introduce a Unified Data Repository (UDR) which, rather than the former 4G User Data Repository, not only stores subscription data but also additional information, such as policy data, data for exposure and application data, for example. Figure 1 shows an exemplary data storage architecture in line with 3GPP TS 23.501 vlS.1.0 (2018-03) in which the 5G UDR contents are accessed via the Nudr interface by consumers, including the User Data Management (UDM), the Policy Control Function (PCF) and the Network

Exposure Function (NEF). More specifically, the UDR supports storage and retrieval of subscription data by the UDM, storage and retrieval of policy data by the PCF, and storage and retrieval of structured data for exposure and application data by the NEF, for example.

The 5G UDR is modeled using the SBA, i.e., it offers services via the Nudr interface. The Nudr interface is defined for the consumers to access particular sets of stored data and, more specifically, to read, update (e.g., add, modify), delete data and subscribe to notifications of relevant data changes in the UDR, for example.

Exemplary data management services provided by the UDR and corresponding operations as well as example consumers in line with 3GPP TS 23.502 vlS.1.0 (2018- 03) are shown in Figure 2. Regarding the data to be accessed, the UDR may accommodate data sets or data subsets (e.g., relating to subscription data, policy data, data for exposure and application data), wherein, in each operation,

parameters may be defined to determine which specific data in the UDR is to be accessed. As an example, for the data set "subscription data", several data subsets which are accessible via the Nudr interface are defined, as exemplarily shown in Figure 3 (together with corresponding data keys and data subkeys) in line with 3GPP TS 23.502 V15.1.0 (2018-03).

According to 3GPP TS 23.501 V15.1.0 (2018-03), it shall be possible to access operator (i.e., vendor) specific data sets by the consumers from the UDR as well as operator specific data for each data set. The content and format/encoding of operator specific data and operator specific data sets are not subject to

standardization, however. In particular, it is not yet solved how operator specific data from different operators may be stored and retrieved in/from a 5G UDR in an appropriate manner.

Summary

Accordingly, there is a need for a technique which enables storing and retrieving vendor specific data of different vendors in/from a common data repository.

According to a first aspect, a method for handling vendor specific data in a system comprising a common data repository requiring a common request format

standardized among a plurality of vendors is provided. The method is performed by a request conversion component and comprises receiving a request to the common data repository from a requesting entity of the system, wherein the request relates to vendor specific data and is in a request format proprietary to a vendor of the requesting entity, converting the request into the common request format, and sending the request to the common data repository.

In the common data repository, vendor specific data may be accessible by requesting entities of different vendors. When the request is a request for storing the vendor specific data in the common data repository, the method may further comprise encrypting the vendor specific data prior to sending the request to the common data repository. When the request is a request for retrieving the vendor specific data from the common data repository, the method may further comprise receiving the vendor specific data from the common data repository in encrypted form, decrypting the vendor specific data, and sending the vendor specific data to the requesting entity.

In one variant, the vendor specific data may be proprietary to the vendor of the requesting entity and the common data repository may be provided by a vendor different from the vendor of the requesting entity. In another variant, the vendor specific data may be proprietary to the vendor of the requesting entity and the common data repository may be provided by the vendor of the requesting entity. In still another variant, the vendor specific data may be proprietary to a vendor different from the vendor of the requesting entity and the common data repository may be provided by a vendor different from the vendor of the requesting entity.

When the system comprises a vendor specific data repository provided by the vendor of the requesting entity and requiring the request format proprietary to the vendor of the requesting entity, the method may further comprise determining, prior to converting the request, whether the request is directed to the common data repository or to the vendor specific data repository, wherein converting the request into the common request format is conditionally performed when it is determined that the request is directed to the common data repository.

When the request format proprietary to the vendor of the requesting entity complies with a first transmission protocol and the common request format complies with a common transmission protocol, converting the request into the common request format may include converting the request from the first transmission protocol to the common transmission protocol. Also, when the request format proprietary to the vendor of the requesting entity complies with a data model proprietary to the vendor of the requesting entity and the common request format complies with a common data model standardized among the plurality of vendors, converting the request into the common request format may include converting the request from the data model proprietary to the vendor of the requesting entity to the common data model.

The common data repository may be a UDR of a mobile communication system and the common transmission protocol and the common data model may comply with a Nudr interface of the UDR. Converting the request into the common request format may include mapping proprietary fields included in the vendor specific data to extensions of at least one of a data set and a data subset of the common data model of the Nudr interface. The request conversion component may be implemented as service of an SBA. According to a second aspect, a method for handling vendor specific data in a system comprising a common data repository requiring a common request format

standardized among a plurality of vendors is provided. The method is performed by the common data repository and comprises receiving, from a request conversion component, a request originating from a requesting entity of the system, the request relating to vendor specific data and converted by the request conversion component from a request format proprietary to a vendor of the requesting entity into the common request format.

The method according to the second aspect defines a method from the perspective of a common data repository which may be complementary to the method performed by the request conversion component according to the first aspect. The request conversion component and the common data repository of the second aspect may correspond to the request conversion component and the common data repository described above in relation to the first aspect. As such, those aspects described with regard to the method of the first aspect which are applicable to the method of the second aspect may be comprised by the method of the second aspect as well, and vice versa.

As in the method of the first aspect, in one variant, the vendor specific data may be proprietary to the vendor of the requesting entity and the common data repository may be provided by a vendor different from the vendor of the requesting entity. When the request is a request for storing the vendor specific data in the common data repository, the method may further comprise storing the vendor specific data in the common data repository in encrypted form. When the request is a request for retrieving the vendor specific data from the common data repository, the method may further comprise sending the vendor specific data to the request conversion component in encrypted form.

In another variant, the vendor specific data may be proprietary to the vendor of the requesting entity and the common data repository may be provided by the vendor of the requesting entity. When the request is a request for storing the vendor specific data in the common data repository, the method may further comprise storing the vendor specific data in the common data repository in at least one of unencrypted form and encrypted form. When the request is a request for retrieving the vendor specific data from the common data repository, the method may further comprise one of (a) when the vendor specific data is stored in the common data repository in encrypted form, sending the vendor specific data to the request conversion component in encrypted form, (b) when the vendor specific data is stored in the common data repository in encrypted form, decrypting the vendor specific data and sending the vendor specific data to the request conversion component in

unencrypted form, and (c) when the vendor specific data is stored in the common data repository in both unencrypted form and encrypted form, selecting a form among the unencrypted form and encrypted form in accordance with at least one criterion and sending the vendor specific data to the request conversion component in the selected form.

In still another variant, the vendor specific data may be proprietary to a vendor different from the vendor of the requesting entity and the common data repository may be provided by a vendor different from the vendor of the requesting entity. When the request is a request for retrieving the vendor specific data from the common data repository, the method may further comprise one of (a) when the vendor specific data is stored in the common data repository in encrypted form, sending the vendor specific data to the request conversion component in encrypted form, and (b) denying the request.

The common request format may comply with a common transmission protocol and with a common data model standardized among the plurality of vendors. The common data repository may be a UDR of a mobile communication system and the common transmission protocol and the common data model may comply with a Nudr interface of the UDR. Proprietary fields included in the vendor specific data may be mapped to extensions of at least one of a data set and a data subset of the common data model of the Nudr interface.

According to a third aspect, a computer program product is provided. The computer program product comprises program code portions for performing the method of at least one of the first aspect and the second aspect when the computer program product is executed on one or more computing devices (e.g., a processor or a distributed set of processors). The computer program product may be stored on a computer readable recording medium, such as a semiconductor memory, DVD, CD- ROM, and so on.

According to a fourth aspect, a computing unit configured to execute a request conversion component for handling vendor specific data in a system comprising a common data repository requiring a common request format standardized among a plurality of vendors is provided. The computing unit comprises at least one processor and at least one memory, wherein the at least one memory contains instructions executable by the at least one processor such that the request conversion

component is operable to perform any of the method steps presented herein with respect to the first aspect.

According to a fifth aspect, a computing unit configured to execute a common data repository for handling vendor specific data in a system comprising a common data repository requiring a common request format standardized among a plurality of vendors is provided. The computing unit comprises at least one processor and at least one memory, wherein the at least one memory contains instructions executable by the at least one processor such that the common data repository is operable to perform any of the method steps presented herein with respect to the second aspect. According to a sixth aspect, there is provided a system comprising a computing unit according to the fourth aspect and a computing unit according to the fifth aspect.

Brief Description of the Drawings Implementations of the technique presented herein are described herein below with reference to the accompanying drawings, in which:

Fig. 1 illustrates an exemplary data storage architecture including a 5G UDR; Fig. 2 illustrates exemplary data management services provided by a 5G UDR;

Fig. 3 illustrates exemplary data subsets of a "subscription data" data set stored in a 5G UDR; Figs. 4a and 4b illustrate exemplary compositions of a computing unit configured to execute a request conversion component and a computing unit configured to execute a common data repository according to the present disclosure; Fig. 5 illustrates a method which may be performed by the request conversion component according to the present disclosure; Fig. 6a illustrates a VendorX consumer accessing a VendorY UDR with VendorX proprietary data;

Fig. 6b illustrates a VendorX consumer accessing a VendorX UDR with VendorX proprietary data;

Fig. 6c illustrates a VendorX consumer accessing a VendorY UDR with respect to

VendorY proprietary data;

Fig. 6d illustrates a VendorX consumer accessing either a VendorY UDR or a

VendorX specific data repository with VendorX proprietary data; and

Fig. 7 illustrates a method which may be performed by the common data

repository according to the present disclosure.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent to one skilled in the art that the present disclosure may be practiced in other embodiments that depart from these specific details.

Those skilled in the art will further appreciate that the steps, services and functions explained herein below may be implemented using individual hardware circuitry, using software functioning in conjunction with a programmed micro-processor or general purpose computer, using one or more Application Specific Integrated Circuits (ASICs) and/or using one or more Digital Signal Processors (DSPs). It will also be appreciated that when the present disclosure is described in terms of a method, it may also be embodied in one or more processors and one or more memories coupled to the one or more processors, wherein the one or more memories are encoded with one or more programs that perform the steps, services and functions disclosed herein when executed by the one or more processors.

Figure 4a schematically illustrates an exemplary composition of a computing unit 400 configured to execute a request conversion component for handling vendor specific data in a system comprising a common data repository requiring a common request format standardized among a plurality of vendors. The computing unit 400 comprises at least one processor 402 and at least one memory 404, wherein the at least one memory 404 contains instructions executable by the at least one processor 402 such that the request conversion component is operable to carry out the method steps described herein below with reference to the request conversion component. Figure 4b schematically illustrates an exemplary composition of a computing unit 410 configured to execute a common data repository for handling vendor specific data in a system comprising a common data repository requiring a common request format standardized among a plurality of vendors. The computing unit 410 comprises at least one processor 412 and at least one memory 414, wherein the at least one memory 414 contains instructions executable by the at least one processor 412 such that the common data repository is operable to carry out the method steps described herein below with reference to the common data repository.

It will be understood that each of the computing unit 400 and the computing unit 410 may be implemented on a physical computing unit or a virtualized computing unit, such as a virtual machine, for example. It will further be appreciated that each of the computing unit 400 and the computing unit 410 may not necessarily be implemented on a standalone computing unit, but may be implemented as

components - realized in software and/or hardware - residing on multiple distributed computing units as well, such as in a cloud computing environment, for example.

Figure 5 illustrates a method which may be performed by the request conversion component executed on the computing unit 400 according to the present disclosure. The method is dedicated to handling vendor specific data in a system comprising a common data repository requiring a common request format standardized among a plurality of vendors. In step S502, the request conversion component may receive a request to the common data repository from a requesting entity of the system, wherein the request relates to vendor specific data and is in a request format proprietary to a vendor of the requesting entity. In step S504, the request conversion component may convert the request into the common request format. In step S506, the request conversion component may send the request to the common data repository.

The request conversion component may thus act as an intermediate component between the requesting entity and the common data repository which may translate the proprietary request format used by the requesting entity into the common request format required by the common data repository. In the following description, the vendor of the requesting entity will also be denoted as "VendorX" and the requesting entity may thus also be called a "VendorX consumer". The request format proprietary to the vendor of the requesting entity (also denoted as "VendorX request format") may correspond to a request format required by a vendor specific data repository provided by the vendor of the requesting entity (also denoted as "VendorX specific data repository"). The VendorX request format may not be compatible with the common request format required by the common data repository and, by converting the request from the VendorX request format into the common request format prior to sending the request to the common data repository, the request conversion component may resolve this incompatibility to thereby enable storage and retrieval of vendor specific data in/from the common data repository, even though the VendorX consumer may operate with a different request format than the common data repository. The request conversion component may act for consumers of different vendors in an equivalent manner (e.g., each vendor having a different vendor specific request format, each differing from the common request format) and, therefore, the request conversion component may generally enable storage and retrieval of vendor specific data of different vendors in/from the common data repository.

The vendor specific data may correspond to data proprietary to a specific vendor. Data specific to VendorX will in the following also be denoted as "VendorX

proprietary data". The vendor specific data may thus either correspond to VendorX proprietary data, i.e., data proprietary to the same vendor as that of the requesting entity, or to data proprietary to a different vendor, such as VendorY, for example. The common data repository itself may also be provided (or operated) by VendorX or by a different vendor, such as VendorY. No matter whether the common data repository is provided by VendorX or by a different vendor, the common data repository may require the same common request format because the common request format may be standardized among a plurality of vendors, as described above.

In the common data repository, vendor specific data may be accessible by requesting entities of different vendors. As such, data stored in the common data repository may generally be accessible (e.g., readable) by any consumer available in the system so that multiple types of consumers may access the same data, even if the data (e.g., not only the same data set but also the same data subsets if the common data repository is a 5G UDR) is proprietary to a different vendor. For example, if VendorX proprietary data is stored in the common data repository, such data may be readable by a consumer of a different vendor, e.g., a VendorY consumer. Similarly, the VendorX proprietary data stored in the common data repository may be accessible by the vendor operating (providing) the common data repository itself. Both situations may be desired to be prevented because the VendorX proprietary data may include application logic and/or business intelligence which may be sensitive to VendorX.

Therefore, in order to ensure that VendorX proprietary data is not accessible by a different vendor (e.g., neither by a VendorY consumer nor by VendorY itself when VendorY operates the common data repository), even though vendor specific data may generally be accessible by entities of different vendors, as described above, vendor specific data may be stored by the request conversion component in encrypted form in the common data repository. The key used for encryption may be managed by the request conversion component. In one variant, the key may only be known to the request conversion component. When the request received in step S502 is thus a request for storing the vendor specific data in the common data repository, the request conversion component may encrypt the vendor specific data prior to sending the request to the common data repository. Similarly, when the request is a request for retrieving the vendor specific data from the common data repository, the request conversion component may receive the vendor specific data from the common data repository in encrypted form, decrypt the vendor specific data, and send the vendor specific data to the requesting entity.

As said, the request to the common data repository may be received from the VendorX consumer, whereas the vendor specific data may either correspond to VendorX proprietary data or to data proprietary to a different vendor (e.g., VendorY proprietary data). Similarly, the common data repository may either be provided (or operated) by VendorX (also denoted as "VendorX common data repository") or by a different vendor (e.g., VendorY). A number of consumer/proprietary data/repository vendor combinations are thus generally conceivable.

In one such variant, the vendor specific data may be proprietary to the vendor of the requesting entity, wherein the common data repository may be provided by a vendor different from the vendor of the requesting entity. In this case, the VendorX consumer may access a VendorY common data repository with VendorX proprietary data. Such situation is exemplarily illustrated Figure 6a, where a VendorX consumer 602 accesses a VendorY UDR 604 (being an example of the common data repository) with VendorX proprietary data. In the shown example, requests from the VendorX consumer 602 use the Lightweight Directory Access Protocol (LDAP) (being an example of part of the request format proprietary to the requesting entity, i.e., the VendorX request format), wherein the request conversion component 606 converts the requests into a Nudr compliant format (being an example of the common request format). Since, in this variant, the VendorX consumer 602 accesses a UDR of a different vendor (i.e., VendorY) with VendorX proprietary data, the request conversion component may store the VendorX proprietary data in the VendorY UDR 604 in encrypted form, as described above, in order to prevent access to the stored data by VendorY or other vendors. When the request received in step S502 is thus a request for storing the vendor specific data in the common data repository, the common data repository may store the vendor specific data in the common data repository in encrypted form. Similarly, when the request is a request for retrieving the vendor specific data from the common data repository, the common data repository may send the vendor specific data to the request conversion component in encrypted form. As mentioned above, the request conversion component may then decrypt the vendor specific data and send the vendor specific data to the requesting entity accordingly.

In another variant, the vendor specific data may be proprietary to the vendor of the requesting entity, wherein the common data repository may be provided by the vendor of the requesting entity. In this case, the VendorX consumer may access a VendorX common data repository with VendorX proprietary data. Such situation is exemplarily illustrated in Figure 6b which equals the example of Figure 6a, the only difference being that the common data repository is given by a VendorX UDR 608 instead of the VendorY UDR 604. Since, in this variant, the VendorX consumer 602 accesses a UDR of the same vendor (i.e., VendorX) with VendorX proprietary data, it is generally conceivable that the VendorX proprietary data may be stored in unencrypted form in the VendorX UDR 608. This may save processing resources. Storing the VendorX proprietary data in unencrypted form may only be performed, however, when all consumers in the system are known to be VendorX consumers, foe example. If it is not known that all consumers in the system are VendorX consumers, the VendorX proprietary data may be stored in encrypted form. When the request received in step S502 is thus a request for storing the vendor specific data in the common data repository, the common data repository may store the vendor specific data in the common data repository in at least one of unencrypted form and encrypted form. When the request is a request for retrieving the vendor specific data from the common data repository, the common data repository may, (a) when the vendor specific data is stored in the common data repository in encrypted form, send the vendor specific data to the request conversion component in encrypted form, (b) when the vendor specific data is stored in the common data repository in encrypted form, decrypt the vendor specific data and send the vendor specific data to the request conversion component in unencrypted form and, (c) when the vendor specific data is stored in the common data repository in both unencrypted form and encrypted form, select a form among the unencrypted form and encrypted form in accordance with at least one criterion and send the vendor specific data to the request conversion component in the selected form.

In the above case (a), the request conversion component may decrypt the vendor specific data and send it to the requesting entity. Thus, in this case, vendor specific data may be stored in encrypted form only and the request conversion component may be responsible for decrypting the data. In the above case (b), vendor specific data may be stored in encrypted form only as well, but it may be the common data repository which is responsible for decrypting the data (provided that the common data repository has access to the key used for encryption), thereby saving processing resources in the request conversion component. In the above case (c), data may be stored in both unencrypted form and encrypted form depending on the type of requesting entity (e.g., data of requesting entities of some vendors may be stored in unencrypted form, while data of requesting entities of other vendors may be stored in encrypted form) and the common data repository may determine which form applies to the respective requesting entity and provide the data in the determined form to the request conversion component.

In still another variant, the vendor specific data may be proprietary to a vendor different from the vendor of the requesting entity, wherein the common data repository may be provided by a vendor different from the vendor of the requesting entity. In this case, the VendorX consumer may access a VendorY common data repository with respect to VendorY proprietary data. Such situation is exemplarily illustrated in Figure 6c which equals the example of Figure 6a, the only difference being that the VendorX consumer accesses the VendorY common data repository with respect VendorY proprietary data and not with respect to VendorX proprietary data. Since, in this variant, the VendorX consumer 602 attempts to access proprietary data of a different vendor (i.e., VendorY), the consumer's access attempt may be blocked or it may at least be ensured that the requested data is not returned to the VendorX consumer 602 in unencrypted form, so that the VendorY proprietary data may not be readable by the VendorX consumer 602. When the request received in step S502 is thus a request for receiving the vendor specific data from the common data repository, the common data repository may, (a) when the vendor specific data is stored in the common data repository in encrypted form, send the vendor specific data to the request conversion component in encrypted form or (b) deny the request. In this way, it may be made sure that the common data repository only returns vendor specific data to a consumer of the same vendor, thereby preventing situations in which vendors have access to other vendors' proprietary data that may be sensitive to the other vendors. By denying the request, useless data transmission may be avoided and bandwidth may be saved accordingly.

In each of the above variants, the request conversion component and/or the common data repository may be able to determine the vendor of the requesting entity and, likewise, the request conversion component and/or the common data repository may be able to determine the vendor associated with the vendor specific data. In one variant, the vendor of the requesting entity may be determined based on network-level information, such as an IP address of the requesting entity, for example. The request conversion component and/or the common data repository may in this case have access to a preconfigured network-level-information/vendor mapping enabling to determine the vendor of the requesting entity based on the network-level information. In another variant, the vendor of the requesting entity may be determined based on at least one parameter included in the request indicating the vendor from which the request originates. This variant may only be applied when requesting entities in the system are trustable. To enable determining the vendor of the vendor specific data, the vendor specific data may be marked accordingly (e.g., when stored in the common data repository), such as using a prefix associated with the data identifying the vendor, for example. As mentioned above, the request format proprietary to the vendor of the requesting entity (i.e., the VendorX request format) may correspond to a request format required by a vendor specific data repository provided by the vendor of the

requesting entity (i.e., a VendorX specific data repository) and converting the request from the VendorX request format into the common request format in accordance with step S504 may be performed to resolve an incompatibility among the request formats. It will be understood that such conversion may not be required when the VendorX consumer directs a request relating to VendorX proprietary data to the VendorX specific data repository (instead of to the common data repository). The request conversion component may thus be configured to convert the request into the common request format only when such conversion is necessary. When the system thus comprises a vendor specific data repository provided by the vendor of the requesting entity and requiring the request format proprietary to the vendor of the requesting entity, the request conversion component may determine, prior to converting the request, whether the request is directed to the common data repository or to the vendor specific data repository, wherein converting the request into the common request format may conditionally be performed when it is determined that the request is directed to the common data repository. Such situation is illustrated in the example of Figure 6d, which generally equals the example of Figure 6a, the only difference being that the system additionally comprises a VendorX specific data repository 610. In the shown example, the request conversion component 606 may identify whether the repository to which the request originating from the VendorX consumer 602 is directed corresponds to a VendorX specific data repository (i.e., the VendorX specific data repository 610) or to a common data repository (i.e., the VendorY UDR 604). Information regarding whether the repository is a VendorX specific data repository or a common data repository may be preconfigured in the request conversion component 606 or may be learned by the request conversion component 606 from messages returned from the repository, such as based on indications of a vendor version included in messages from the repository, for example.

When the request conversion component 606 determines that the data repository is a VendorX specific data repository, no conversion may be required and the request conversion component 606 may thus forward the received LDAP request to the VendorX specific data repository 610 without conversion. In one variant, it may be conceivable that the VendorX specific data repository corresponds to a 5G UDR which supports an LDAP interface (e.g., based on a former 3GPP reference point) with a proprietary data model which defines vendor specific data fields. This may allow continuing pre-5G provisioning with a 5G UDR. When the request conversion component 606 determines that the data repository is a common data repository, on the other hand, the request conversion component 606 may perform the conversion of the received LDAP request to a format compliant with the Nudr interface before forwarding the request to the VendorY UDR 604, as described above.

Converting the request into the common request format may include at least one of a conversion of a transmission protocol and a conversion of a data model used to convey the vendor specific data. When the request format proprietary to the vendor of the requesting entity (i.e., the VendorX request format) complies with a first transmission protocol and the common request format complies with a common transmission protocol (e.g., a second transmission protocol different from the first transmission protocol), converting the request into the common request format may include converting the request from the first transmission protocol to the common transmission protocol. Referring to the examples of Figures 6a to 6 d above, the first transmission protocol may correspond to LDAP and the common transmission protocol may correspond to a Nudr compliant transmission protocol, such as a HTTP/REST, for example. Similarly, when the request format proprietary to the vendor of the requesting entity (i.e., the VendorX request format) complies with a data model proprietary to the vendor of the requesting entity (also denoted as "VendorX data model") and the common request format complies with a common data model standardized among the plurality of vendors, converting the request into the common request format may include converting the request from the data model proprietary to the vendor of the requesting entity to the common data model.

Referring again to the examples of Figures 6a to 6d above, the VendorX data model may correspond to a data model used in LDAP requests proprietary to VendorX and the common data model may correspond to a Nudr compliant data model, i.e., a data model in which data is structured for compliance with the Nudr interface (e.g., structured into data sets and data subsets, as described above).

The common data repository may thus be a UDR of a mobile communication system (e.g., a 5G UDR), wherein the common transmission protocol and the common data model may comply with a Nudr interface of the UDR. Converting the request into the common request format may in this case include mapping proprietary fields included in the vendor specific data to extensions of at least one of a data set and a data subset of the common data model of the Nudr interface. In other words, internal proprietary fields included in the vendor specific data may be mapped to vendor specific extensions of at least one of a data set and a data subset of the common data model. The extensions may be defined as part of a standard JavaScript Object Notation (JSON) body (e.g., in REST, conveyed using a HTTP), such as in the form of a naming convention where each vendor specific attribute is defined with a vendor specific prefix, for example. The same may generally apply to operations defined in accordance with the data model, i.e., the request conversion component may map operations defined in connection with the VendorX data model (e.g., LDAP

operations) into corresponding operations defined by the Nudr interface. The operations may in this case be adapted when needed. For example, as the Nudr interface may not allow reading a single attribute but only a whole data subset, the request conversion component may read the whole data subset and apply a filter for the required attribute.

The vendor may be an operator of the mobile communication system, for example, and the requesting entity may be a consumer of the mobile communication system, such as a UDM, PCF or NEF, as described above. In one variant, the common data repository may correspond to a UDR and the requesting entity may correspond to a consumer in accordance with 3GPP TS 23.501 vlS.1.0 (2018-03) and 3GPP TS 23.502 V15.1.0 (2018-03), or successor versions thereof. It will be understood that, although the common data repository may be a UDR of a mobile communication system, the common data repository may generally correspond to any kind of database system capable of storing vendor proprietary data and supporting multivendor consumer access. It will further be understood that the common data repository may correspond to a single logical entity, but may be implemented using different physical databases, e.g., providing support for replication and high availability. The request conversion component may in one variant be implemented as an intermediate element or service between the requesting entity and the common data repository. In other variants, the request conversion component may be implemented as part of the requesting entity or as part of the common data repository itself. Generally, the request conversion component may be implemented as a service of an SBA.

Figure 7 illustrates a method which may be performed by the common data repository executed on the computing unit 410 according to the present disclosure. The method is dedicated to handling vendor specific data in a system comprising a common data repository requiring a common request format standardized among a plurality of vendors. The operation of the common data repository may be

complementary to the operation of the request conversion component described above in relation to Figure 5 and, as such, aspects described above with regard to the operation of the common data repository may be applicable to the operation of the common data repository executed on the computing unit 410 described in the following as well. Unnecessary repetitions are thus omitted in the following.

In step S702, the common data repository may receive, from a request conversion component, a request originating from a requesting entity of the system, the request relating to vendor specific data and converted by the request conversion component from a request format proprietary to a vendor of the requesting entity into the common request format. As described above in relation to Figures 5 and 6a to 6d, in one variant, the vendor specific data may be proprietary to the vendor of the requesting entity and the common data repository may be provided by a vendor different from the vendor of the requesting entity. When the request is a request for storing the vendor specific data in the common data repository, the common data repository may store the vendor specific data in the common data repository in encrypted form. When the request is a request for retrieving the vendor specific data from the common data repository, the common data repository may send the vendor specific data to the request conversion component in encrypted form. In another variant, the vendor specific data may be proprietary to the vendor of the requesting entity and the common data repository may be provided by the vendor of the requesting entity. When the request is a request for storing the vendor specific data in the common data repository, the common data repository may store the vendor specific data in the common data repository in at least one of unencrypted form and encrypted form. When the request is a request for retrieving the vendor specific data from the common data repository, the common data repository may perform one of (a) when the vendor specific data is stored in the common data repository in encrypted form, sending the vendor specific data to the request conversion component in encrypted form, (b) when the vendor specific data is stored in the common data repository in encrypted form, decrypting the vendor specific data and sending the vendor specific data to the request conversion component in unencrypted form, and (c) when the vendor specific data is stored in the common data repository in both unencrypted form and encrypted form, selecting a form among the unencrypted form and encrypted form in accordance with at least one criterion and sending the vendor specific data to the request conversion component in the selected form.

In still another variant, the vendor specific data may be proprietary to a vendor different from the vendor of the requesting entity and the common data repository may be provided by a vendor different from the vendor of the requesting entity. When the request is a request for retrieving the vendor specific data from the common data repository, the common data repository may perform one of (a) when the vendor specific data is stored in the common data repository in encrypted form, sending the vendor specific data to the request conversion component in encrypted form, and (b) denying the request.

The common request format may comply with a common transmission protocol and with a common data model standardized among the plurality of vendors. The common data repository may be a UDR of a mobile communication system and the common transmission protocol and the common data model may comply with a Nudr interface of the UDR. Proprietary fields included in the vendor specific data may be mapped to extensions of at least one of a data set and a data subset of the common data model of the Nudr interface. As a further aspect of the present disclosure, in some variants, it may be conceivable that the VendorX consumer and the common data repository use the same request format (e.g., the same transmission protocol and same data model), i.e., the

VendorX request format may be equal to the common request format. For example, the VendorX consumer may use HTTP/REST and a Nudr compliant data model, i.e., in the same manner as the common data repository, and the request conversion component may therefore not be required to perform a conversion. The request conversion component may in this case support all features described above, except for the conversion related features. The request conversion component may in this case particularly encrypt the vendor specific data prior to sending the request to the common data repository, as described above.

According to a further aspect, the present disclosure may thus also comprise a method for handling vendor specific data in a system comprising a common data repository requiring a common request format standardized among a plurality of vendors, wherein the method may be performed by a request conversion component and may comprise receiving a request to the common data repository from a requesting entity of the system, wherein the request relates to vendor specific data, encrypting the vendor specific data prior to sending the request to the common data repository, and sending the request to the common data repository. The method according to this aspect may comprise all features described above in relation to the method performed by the request conversion component, wherein the conversion related features may be optional features of the method. The method may be executed on computing unit 400, for example.

According to a still further aspect, the present disclosure may also comprise a method for handling vendor specific data in a system comprising a common data repository requiring a common request format standardized among a plurality of vendors, wherein the method may be performed by the common data repository and may comprise receiving, from a request conversion component, a request originating from a requesting entity of the system, the request relating to vendor specific data and being encrypted by the request conversion component. The method according to this aspect may comprise all features described above in relation to the method performed by the common data repository, wherein the conversion related features may be optional features of the method. The method may be executed on computing unit 410, for example. As has become apparent from the above, the present disclosure provides a technique for handling vendor specific data in a system comprising a common data repository requiring a common request format standardized among a plurality of vendors. The presented technique may enable storing and retrieving vendor specific data of different vendors in/from a common data repository, such as a 5G UDR, for example. The technique may ensure that proprietary data of one vendor stored in the common data repository is not accessible (e.g., readable) by another vendor, e.g., neither by a consumer provided by another vendor or, in case the common data repository is provided by the other vendor, by the other vendor itself. Vendor proprietary data stored in the common data repository may in this way be kept private against other vendors. The technique herein presented may also save processing resources for certain components of the system and may reduce the amount of data read from the common data repository because consumers may only read data which is relevant for the particular consumer, i.e., data which is associated with the same vendor as that of the consumer.

It is believed that the advantages of the technique presented herein will be fully understood from the foregoing description, and it will be apparent that various changes may be made in the form, constructions and arrangement of the exemplary aspects thereof without departing from the scope of the invention or without sacrificing all of its advantageous effects. Because the technique presented herein can be varied in many ways, it will be recognized that the invention should be limited only by the scope of the claims that follow.