Patent Description:
Next generation networks, such as Fifth Generation (<NUM>), denote the next major phase of mobile telecommunications standards beyond Fourth Generation (<NUM>) standards. In comparison to <NUM> networks, next generation networks may be enhanced in terms of radio access and network architecture. Next generation networks intend to utilize new regions of the radio spectrum for Radio Access Networks (RANs), such as millimeter wave bands.

<NUM> Core Network Functions (NFs) often process sensitive data that needs to be protected from unauthorized access (e.g., UE identities, such as SUPI, UE authentication data, such as keys, whether a UE is a "Priority user" and has privileged access to the network during overload, etc.). Thus, it is desirable to identify mechanisms or standards for encryption of data that is stored in an NF.

The documents
"<NPL>,
"<NPL>, and
<CIT>
represent relevant prior art.

Described herein are enhanced data repository services of a <NUM> core network. In general, an NF that provides a data repository service to NF service consumers also supports encryption as a service. A data repository NF as described herein is configured to encrypt/decrypt certain data (e.g., sensitive data) in records based on one or more encryption indicators embedded in a meta schema for the records. One technical benefit is the protection of data is specified in the meta schema, and thus the same protection level may be applied across different data repository NFs.

In one embodiment, a data repository NF comprises at least one processor and at least one memory including computer program code. The memory and the computer program code are configured to, with the processor, cause the data repository NF at least to receive a request from an NF service consumer for a service operation regarding storage of a record, and containing meta and/or one or more blocks of the record. The processor further causes the data repository NF to apply encryption to one or more meta tags of the meta and/or to the blocks of the record based on one or more encryption indicators embedded in a meta schema defined for the meta, and store the record with the one or more meta tags and/or the blocks in encrypted format according to the meta schema.

In one embodiment, the processor further causes the data repository NF to receive another request from the same or another NF service consumer for a service operation regarding retrieval of the record having the one or more meta tags and/or the blocks stored in encrypted format, decrypt the one or more meta tags and/or the blocks of the record based on the encryption indicators embedded in the meta schema, and send a response to the NF service consumer with the one or more meta tags and/or the blocks in unencrypted format.

In one embodiment, the processor further causes the data repository NF to receive another request from the same or another NF service consumer for a service operation regarding a search of records having the one or more meta tags stored in encrypted format, perform a comparison of the one or more meta tags stored in encrypted format with a comparison value specified in filter criteria, and send a response to the NF service consumer containing a search result.

In one embodiment, the processor further causes the data repository NF to decrypt the one or more meta tags indicated in the filter criteria, and compare the one or more meta tags in unencrypted format with the comparison value.

In one embodiment, the processor further causes the data repository NF to encrypt the comparison value, and compare the one or more meta tags in encrypted format with the encrypted comparison value.

In one embodiment, the meta schema includes a block encryption indicator of the encryption indicators indicating that the blocks of the record are stored in encrypted format.

In one embodiment, a meta schema data type of the meta schema includes the block encryption indicator.

In one embodiment, the meta schema includes a tag encryption indicator of the encryption indicators indicating that tag values of a meta tag of the record are stored in encrypted format.

In one embodiment, a tag type data type of the meta schema includes the tag encryption indicator.

In one embodiment, the encryption indicators refer to an encryption enumeration that indicates encryption methods for records stored in the data repository NF.

In one embodiment, a supported features data type includes an encryption feature indicator indicating that the data repository NF supports encryption as a service.

In one embodiment, the processor further causes the data repository NF to register an encryption capability in an NF Repository Function (NRF).

In one embodiment, the data repository NF is implemented in an Unstructured Data Storage Function (UDSF).

In one embodiment, the data repository NF is implemented in a Unified Data Repository (UDR).

In one embodiment, the data repository NF is implemented in an Analytics Data Repository Function (ADRF).

In one embodiment, a method of performing a data repository service in a <NUM> core network is disclosed. The method comprises receiving a request from an NF service consumer for a service operation regarding storage of a record, and containing meta and/or one or more blocks of the record. The method further comprises applying encryption to one or more meta tags of the meta and/or to the blocks of the record based on one or more encryption indicators embedded in a meta schema defined for the meta, and storing the record with the one or more meta tags and/or the blocks in encrypted format according to the meta schema.

In one embodiment, the method further comprises receiving another request from the same or another NF service consumer for a service operation regarding retrieval of the record having the one or more meta tags and/or the blocks stored in encrypted format, decrypting the one or more meta tags and/or the blocks of the record based on the encryption indicators embedded in the meta schema, and sending a response to the NF service consumer with the one or more meta tags and/or the blocks in unencrypted format.

In one embodiment, the method further comprises receiving another request from the same or another NF service consumer for a service operation regarding a search of records having the one or more meta tags stored in encrypted format, performing a comparison of the one or more meta tags stored in encrypted format with a comparison value specified in filter criteria, and sending a response to the NF service consumer containing a search result.

In one embodiment, a data repository NF comprises a means for receiving a request from an NF service consumer for a service operation regarding storage of a record, and containing meta and/or one or more blocks of the record. The data repository NF further comprises a means for applying encryption to one or more meta tags of the meta and/or to the blocks of the record based on one or more encryption indicators embedded in a meta schema defined for the meta. The data repository NF further comprises a means for storing the record with the one or more meta tags and/or the blocks in encrypted format according to the meta schema.

Other embodiments may include computer readable media, other systems, or other methods as described below. The various features of the different embodiments may be variously combined with some features included and others excluded to suit a variety of different applications.

The above summary provides a basic understanding of some aspects of the specification. This summary is not an extensive overview of the specification. It is intended to neither identify key or critical elements of the specification nor delineate any scope of the particular embodiments of the specification, or any scope of the claims. Its sole purpose is to present some concepts of the specification in a simplified form as a prelude to the more detailed description that is presented later.

Some embodiments of the invention are now described, by way of example only, and with reference to the accompanying drawings.

The figures and the following description illustrate specific exemplary embodiments. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the embodiments and are included within the scope of the embodiments. Furthermore, any examples described herein are intended to aid in understanding the principles of the embodiments, and are to be construed as being without limitation to such specifically recited examples and conditions. As a result, the inventive concept(s) is not limited to the specific embodiments or examples described below, but by the claims.

<FIG> illustrates a high-level architecture of a <NUM> system <NUM>. A <NUM> system <NUM> is a communication system (e.g., a 3GPP system) comprising a <NUM> Access Network ((R)AN) <NUM>, a <NUM> Core Network (CN) <NUM> (also referred to as 5GC), and <NUM> User Equipment (UE) <NUM>. Access network <NUM> may comprise an NG-RAN and/or a non-3GPP access network connecting to a <NUM> core network <NUM>. Access network <NUM> may support Evolved-UMTS Terrestrial Radio Access Network (E-UTRAN) access (e.g., through an eNodeB, gNodeB, and/or ng-eNodeB), Wireless Local Area Network (WLAN) access, fixed access, satellite radio access, new Radio Access Technologies (RAT), etc. Core network <NUM> interconnects access network <NUM> with a data network (DN) <NUM>. Core network <NUM> is comprised of Network Functions (NF) <NUM>, which may be implemented either as a network element on dedicated hardware, as a software instance running on dedicated hardware, as a virtualized function instantiated on an appropriate platform (e.g., a cloud infrastructure), etc. Data network <NUM> may be an operator external public or private data network, or an intra-operator data network (e.g., for IMS services). UE <NUM> is a <NUM> capable device configured to register with core network <NUM> to access services. UE <NUM> may be an end user device, such as a mobile phone (e.g., smartphone), a tablet or PDA, a computer with a mobile broadband adapter, etc. UE <NUM> may be enabled for voice services, data services, Machine-to-Machine (M2M) or Machine Type Communications (MTC) services, and/or other services.

<FIG> illustrates a non-roaming architecture <NUM> of a <NUM> system. The architecture <NUM> in <FIG> is a service-based representation, as is further described in 3GPP TS <NUM> (v17. <NUM><NUM>). Architecture <NUM> is comprised of Network Functions (NF) for a core network <NUM>, and the NFs for the control plane (CP) are separated from the user plane (UP). The control plane of the core network <NUM> includes an Authentication Server Function (AUSF) <NUM>, an Access and Mobility Management Function (AMF) <NUM>, a Session Management Function (SMF) <NUM>, a Policy Control Function (PCF) <NUM>, a Unified Data Management (UDM) <NUM>, a Network Slice Selection Function (NSSF) <NUM>, and an Application Function (AF) <NUM>. The control plane of the core network <NUM> further includes a Network Exposure Function (NEF) <NUM>, a NF Repository Function (NRF) <NUM>, a Service Communication Proxy (SCP) <NUM>, a Network Slice Admission Control Function (NSACF) <NUM>, a Network Slice-specific and SNPN Authentication and Authorization Function (NSSAAF) <NUM>, and an Edge Application Server Discovery Function (EASDF) <NUM>. The user plane of the core network <NUM> includes one or more User Plane Functions (UPF) <NUM> that communicate with data network <NUM>. UE <NUM> is able to access the control plane and the user plane of the core network <NUM> through (R)AN <NUM>. Other NFs of a <NUM> system not shown in <FIG> include an Unstructured Data Storage Function (UDSF), a Unified Data Repository (UDR), and an Analytics Data Repository Function (ADRF).

Various network functions of <NUM> system <NUM> may also be referred to herein as "network elements". A "network element" includes functions, operations, etc., and the underlying hardware or physical devices (e.g., processors) that are programmed to perform the functions.

The <NUM> architecture is based on a Service-Based Architecture (SBA), which is delivered by a set of interconnected Network Functions (NFs), with authorization to access each other's services. The roles of NFs with the 5GC may be defined as a service consumer and a service producer. An NF service producer is an NF that exposes an NF service, and an NF service consumer is an NF that requests an NF service. An NF service may communicate directly between an NF service consumer and an NF service producer through a service-based interface (SBI), as illustrated in <FIG>. An NF service may also communicate between an NF service consumer and NF service producers indirectly via an SCP <NUM> (not shown). The end-to-end interaction between two NFs (Consumer and Producer) within the NF service framework follows two mechanisms: "Request-response", and "Subscribe-Notify". <FIG> illustrates a "Request-response" NF Service mechanism. An NF service consumer <NUM> sends a request <NUM> for a certain NF service to NF service producer <NUM>. NF service producer <NUM> provides an NF service based on the request <NUM> from NF service consumer <NUM>. In order to fulfill the request <NUM>, NF service producer <NUM> may in turn consume NF services from other NFs. In the Request-response mechanism, a one-time response <NUM> from NF service producer <NUM> to NF service consumer <NUM> is expected within a certain timeframe.

Some NF services provided within a <NUM> architecture are data storage or data repository services.

<FIG> is a block diagram of a data repository NF <NUM> in an illustrative embodiment. Data repository NF <NUM> is a network element or network function (NF) of a <NUM> core network <NUM> that is configured to store data as part of a data repository service. Examples of data repository NF <NUM> include an Unstructured Data Storage Function (UDSF), a Unified Data Repository (UDR), and an Analytics Data Repository Function (ADRF), although other NFs are considered herein that provide a data repository service.

In one embodiment, data repository NF <NUM> includes the following subsystems: a network interface component <NUM>, a data management controller <NUM>, and a data store <NUM> that operate on one or more platforms. Network interface component <NUM> may comprise circuitry, logic, hardware, means, etc., configured to exchange control plane messages or signaling with other network elements or NFs. Network interface component <NUM> may operate using a variety of protocols or reference points. Data management controller <NUM> may comprise circuitry, logic, hardware, means, etc., configured to support a data repository service. Data store <NUM> comprises a data storage mechanism, memory, database, etc., that is configured to store data.

One or more of the subsystems of data repository NF <NUM> may be implemented on a hardware platform comprised of analog and/or digital circuitry. For example, data management controller <NUM> may be implemented on one or more processors <NUM> that execute instructions <NUM> (i.e., computer readable code) for software that are loaded into memory <NUM>. A processor <NUM> comprises an integrated hardware circuit configured to execute instructions <NUM> to provide the functions of data repository NF <NUM>. Processor <NUM> may comprise a set of one or more processors or may comprise a multi-processor core, depending on the particular implementation. Memory <NUM> is a non-transitory computer readable storage medium for data, instructions, applications, etc., and is accessible by processor <NUM>. Memory <NUM> is a hardware storage device capable of storing information on a temporary basis and/or a permanent basis. Memory <NUM> may comprise a random-access memory, or any other volatile or non-volatile storage device. One or more of the subsystems of data repository NF <NUM> may be implemented on a cloud-computing platform or another type of processing platform.

Data repository NF <NUM> may include various other components not specifically illustrated in <FIG>.

In general, a data repository NF <NUM> as described herein is configured to store data in records <NUM>. <FIG> is a block diagram of a record <NUM> for a data repository service. Record <NUM> is identifiable with a record identifier (e.g., recordId). Record <NUM> includes meta <NUM> and may include one or more blocks <NUM> of data. Meta <NUM> includes one or more meta tags <NUM>, which is a map of tag name/value(s) pairs. A tag name <NUM> is a unique string name that is the primary key of the map, and is paired with one or more tag values <NUM> (i.e., an array of string values). Meta <NUM> also includes a schema ID <NUM> that indicates a meta schema for the meta <NUM> (e.g., the meta tags <NUM>). Blocks <NUM> (e.g., block <NUM>-<NUM> and <NUM>-<NUM>) of a record <NUM> (if present) are identifiable with a block identifier (e.g., blockId).

In <FIG>, data repository NF <NUM> stores a meta schema <NUM> (or multiple meta schemas) for the data repository service. A meta schema <NUM> indicates or describes the data structure of the meta tags <NUM> for records <NUM>.

The data repository service may provide for multiple service operations. One service operation is a record collection operation to search for or delete records <NUM>. One service operation is a record operation to retrieve, create, update, or delete a record <NUM>. One service operation is a meta operation to retrieve the meta <NUM> of a record <NUM> or modify the meta <NUM> of a record <NUM>. One service operation is a block collection operation to retrieve all blocks <NUM> of a record <NUM>. One service operation is a block operation to retrieve, create, update, or delete a block <NUM>. One service operation is a meta schema operation to retrieve, create, update, or delete a meta schema <NUM>. Other service operations, such as subscription operations, are also defined.

For a data repository service, data repository NF <NUM> acts as an NF service producer <NUM> for an NF service consumer <NUM>. Thus, an NF service consumer <NUM> may send a request to data repository NF <NUM> to store one or more records <NUM>, may send a request to data repository NF <NUM> to retrieve one or more records <NUM>, etc. At least a portion of a record <NUM> may comprise sensitive data, which is data that is protected against unauthorized access or unwarranted disclosure. To provide a protection mechanism for the sensitive data, data repository NF <NUM> implements an encryption service as part of the data repository service. Thus, data repository NF <NUM> may be configured to encrypt meta tags <NUM> and/or blocks <NUM> of a record <NUM> for storage. In one embodiment, one or more encryption indicators <NUM> are included or embedded in the meta schema <NUM>. Encryption indicators <NUM> embedded in the meta schema <NUM> may indicate which meta tags <NUM> are to be encrypted as stored by data repository NF <NUM>, whether blocks <NUM> are to encrypted as stored by data repository NF <NUM>, an encryption method for encryption, etc..

<FIG> is a flow chart illustrating a method <NUM> of performing a data repository service in an illustrative embodiment. The steps of method <NUM> will be described with reference to data repository NF <NUM> in <FIG>, but those skilled in the art will appreciate that method <NUM> may be performed in other systems, devices, or network functions. The steps of the flow charts described herein are not all inclusive and may include other steps not shown, and the steps may be performed in an alternative order.

In this method, data repository NF <NUM> acts as an NF service producer <NUM> for a data repository service where an NF service consumer <NUM> stores a record <NUM> at data repository NF <NUM>. Data management controller <NUM> receives a request from an NF service consumer <NUM> for a service operation regarding storage of a record <NUM> (step <NUM>), such as through network interface component <NUM>. The request contains data for the record <NUM> supplied by the NF service consumer <NUM>, such as meta <NUM> and/or one or more blocks <NUM> of the record <NUM>. For example, data management controller <NUM> may receive a request to create or update a record <NUM>, and the request body contains meta <NUM> and zero or more blocks <NUM> of the record <NUM>. In another example, data management controller <NUM> may receive a request to modify meta <NUM> of the record <NUM>, and the request body contains meta <NUM> (e.g., patch items to apply to the record <NUM>). In another example, data management controller <NUM> may receive a request to create or update a block <NUM> of the record <NUM>, and the request body contains the block data for the block <NUM>.

Data management controller <NUM> is configured to encrypt certain data (e.g., sensitive data) in the record <NUM> based on the meta schema <NUM> designated for the record <NUM>. It may therefore be assumed that the data to be encrypted by data repository NF <NUM> is not encrypted by NF service consumer <NUM>. For example, NF service consumer <NUM> may know based on the meta schema <NUM> what data will be encrypted at data repository NF <NUM> as part of the data repository service. Thus, NF service consumer <NUM> may leave this data in unencrypted format within record <NUM>. Other parts of record <NUM> (e.g., data that will not be encrypted by data repository NF <NUM>) may be encrypted by the NF service consumer <NUM>.

Data management controller <NUM> applies encryption to one or more meta tags <NUM> of the meta <NUM> and/or to the blocks <NUM> of the record <NUM> based on the encryption indicators <NUM> embedded in the meta schema <NUM> (step <NUM>). Data management controller <NUM> then stores the record <NUM> with the meta tag(s) <NUM> and/or the blocks <NUM> in encrypted format according to the meta schema <NUM> (step <NUM>), such as in data store <NUM>. Data management controller <NUM> may also send a response to the NF service consumer <NUM> with a status code for the prior request.

The encryption/protection of data within data repository NF <NUM> is orthogonal to encryption/protection of data during transmission from one NF to another. The latter is achieved with the existing mechanisms, such as mutual Transport Layer Security (TLS) or mTLS that applies to Service Based Interfaces.

Data repository NF <NUM> may repeat method <NUM> for the same or other NF service consumers <NUM>, and apply encryption to selected portions of records <NUM> based on the meta schema <NUM>.

<FIG> is a flow chart illustrating a method <NUM> of performing a data repository service in an illustrative embodiment. In this method, data repository NF <NUM> acts as an NF service producer <NUM> for a data repository service where an NF service consumer <NUM> retrieves data from data repository NF <NUM>. Data management controller <NUM> of data repository NF <NUM> receives a request from the same or another NF service consumer <NUM> for a service operation regarding retrieval of a record <NUM> having the meta tag(s) <NUM> and/or block(s) <NUM> stored in encrypted format (step <NUM>), such as through network interface component <NUM>. For example, data management controller <NUM> may receive a request to retrieve the record <NUM>, to retrieve the meta <NUM> of the record <NUM>, to retrieve a block <NUM> or all blocks <NUM> of the record <NUM>, etc. In response to the request, data management controller <NUM> decrypts the meta tag(s) <NUM> and/or block(s) <NUM> of the record(s) <NUM> based on the encryption indicators <NUM> embedded in the meta schema <NUM> (step <NUM>). Data management controller <NUM> then sends a response to the NF service consumer <NUM> containing the meta tag(s) <NUM> and/or block(s) <NUM> in unencrypted format (step <NUM>), such as through network interface component <NUM>.

Data repository NF <NUM> may repeat method <NUM> for the same or other NF service consumers <NUM>.

<FIG> is a flow chart illustrating a method <NUM> of performing a data repository service in an illustrative embodiment. In this method, data repository NF <NUM> acts as an NF service producer <NUM> for a data repository service where an NF service consumer <NUM> searches data stored in data repository NF <NUM>. Data management controller <NUM> of data repository NF <NUM> receives a request from the same or another NF service consumer <NUM> for a service operation regarding a search of records <NUM> having meta tag(s) <NUM> stored in encrypted format (step <NUM>). The request from the NF service consumer <NUM> includes filter criteria for searching the records <NUM>, and the filter criteria includes or specifies a comparison value (or multiple comparison values). For the search, data management controller <NUM> performs a comparison of meta tags <NUM> stored in encrypted format with the comparison value (step <NUM>). In one embodiment, data management controller <NUM> may decrypt meta tags <NUM> indicated in the filter criteria (step <NUM>), and compare the meta tags <NUM> in unencrypted format with the comparison value (step <NUM>). Alternatively, data management controller <NUM> may encrypt the comparison value (step <NUM>), and compare the meta tags <NUM> in encrypted format with the encrypted comparison value (step <NUM>). Data management controller <NUM> then sends a response to the NF service consumer <NUM> containing the search result (step <NUM>), i.e., containing the record references matching the filter criteria.

One technical benefit of the encryption service described above is a data repository NF <NUM> is responsible for implementing the encryption/decryption of the relevant meta <NUM> and/or blocks <NUM> of records <NUM> stored in data repository NF <NUM> based on the encryption indicators <NUM> in the meta schema <NUM>. Thus, encryption keys remain local to the data repository NF <NUM>, and do not need to be shared between data repository NF <NUM> and NF service consumers <NUM>. The encryption service within a data repository NF <NUM> may be used in parallel with encryption applied by NF service consumers <NUM>. For example, NF service consumers <NUM> may perform block encryption/decryption and use the encryption service to protect meta tags <NUM>. Another technical benefit is encryption can be applied on per-need basis for specific meta tags <NUM> and/or blocks <NUM> based on the encryption indicators <NUM> in the meta schema <NUM>. Another technical benefit is meta tags <NUM> may be stored in encrypted format even when data repository NF <NUM> needs to process in nonencrypted format in order to perform searches, which improves security.

In one embodiment, data repository NF <NUM> may comprise or may be implemented in a UDSF. <FIG> illustrates a data storage architecture with a UDSF <NUM>. UDSF <NUM> is an NF configured to provide a UDSF data repository service (e.g., Nudsf_DataRepository Service) as described in 3GPP TS <NUM> (v17. <NUM><NUM>). UDSF <NUM> acts as an NF service producer <NUM>, and provides the UDSF data repository service to an NF service consumer <NUM>. The UDSF data repository service allows NF service consumers <NUM> to retrieve, create, update, and delete data stored in UDSF <NUM>. Any NF may use UDSF <NUM> to store unstructured data (i.e., data for which the structure is not defined in 3GPP specifications). UDSF <NUM> belongs to the same PLMN where the NF service consumer <NUM> is located. NFs may share a UDSF <NUM> for storing their respective unstructured data or may each have their own UDSF <NUM>.

To provide an encryption service in UDSF <NUM>, for example, the data structure of the UDSF data repository service may be extended to include an encryption indicator <NUM> (i.e., block encryption indicator) that indicates whether UDSF <NUM> is to encrypt blocks <NUM> of a record <NUM>. The data structure of the UDSF data repository service may be extended to include an encryption indicator <NUM> (i.e., tag encryption indicator) that indicates whether UDSF <NUM> is to encrypt one or more meta tags <NUM> (i.e., tag values <NUM>) of a record <NUM>.

The data model supported by the UDSF data repository service (i.e., Nudsf_DataRepository service) Application Programming Interface (API) includes multiple structured data types (see, for example, section <NUM>. <NUM> of 3GPP TS <NUM>). One of the data types is the "MetaSchema" data type (see, for example, section <NUM>. <NUM> of 3GPP TS <NUM>) that describes the meta schema <NUM>. <FIG> illustrates the "MetaSchema" data type <NUM> in an illustrative embodiment. The "MetaSchema" data type <NUM> includes the following mandatory attributes or Information Elements (IE): a "schemaId" attribute <NUM>, and a "metaTags" attribute <NUM>. The "schemaId" attribute <NUM> indicates the meta schema <NUM>, and the "metaTags" attribute <NUM> is an array of tag types that describes the meta schema <NUM>. In one embodiment, the "MetaSchema" data type <NUM> is extended to include an optional encryption indicator <NUM>, which comprises a block encryption indicator <NUM> (also referred to as attribute or IE). The block encryption indicator <NUM> (i.e., "blockEncryption") indicates that encryption is directed, instructed, or required for the blocks <NUM> of records <NUM> stored by UDSF <NUM>. Absence of this indicator indicates that no encryption is required. Although the name "blockEncryption" is illustrated for the block encryption indicator <NUM> in <FIG>, other attribute names may be used.

Another of the data types is the "TagType" data type (see, for example, section <NUM>. <NUM> of 3GPP TS <NUM>). <FIG> illustrates the "TagType" data type <NUM> in an illustrative embodiment. The "TagType" data type <NUM> includes the following mandatory attributes or IEs: a "tagName" attribute <NUM>, and a "keyType" attribute <NUM>. The "tagName" attribute <NUM> indicates the tag name <NUM> of the meta tag <NUM>. The "keyType" attribute <NUM> is the type of key. In one embodiment, the "TagType" data type <NUM> is extended to include an optional encryption indicator <NUM>, which comprises a tag encryption indicator <NUM> (also referred to as attribute or IE). The tag encryption indicator <NUM> (i.e., "tagEncryption") indicates that encryption is directed, instructed, or required for the tag values <NUM> mapped to the tag name <NUM> as stored by UDSF <NUM>. Absence of this indicator indicates that no encryption is required. Although the name "tagEncryption" is illustrated for the tag encryption indicator <NUM> in <FIG>, other attribute names may be used.

The data model supported by the UDSF data repository service API also includes simple data types and enumerations (see, for example, section <NUM>. <NUM> of 3GPP TS <NUM>). The block encryption indicator <NUM> and the tag encryption indicator <NUM> each refer to an encryption data type. The data model may be extended to include a new encryption enumeration that indicates encryption methods (i.e., referring to the target or supported key algorithms and the associated key sizes) for records <NUM> stored in UDSF <NUM>. <FIG> illustrates an encryption enumeration <NUM> in an illustrative embodiment. Encryption enumeration <NUM> (which may be labeled section <NUM>. <NUM>-x in 3GPP TS <NUM>) indicates a plurality of enumeration values <NUM> as follows: no encryption (or "NULL"), AES-<NUM>, AES-<NUM>, AES-<NUM>, and UDSF_DEFINED. The AES-<NUM> enumeration value indicates that the encryption method is based on the AES-<NUM> encryption standard, the AES-<NUM> enumeration value indicates that the encryption method is based on the AES-<NUM> encryption standard, and the AES-<NUM> enumeration value indicates that the encryption method is based on the AES-<NUM> encryption standard. The UDSF_DEFINED enumeration value indicates that the encryption method is based on a local policy of UDSF <NUM>. <FIG> illustrates a non-exhaustive list of possible encryption enumeration values, and others may be defined or standardized.

According to the 3GPP, for any API that defines resources, suitable resources associated to or representing the NF service consumer <NUM> are identified in each API to support the negotiation of the applicable optional features between the NF service consumer <NUM> and the NF service producer <NUM> for the resource (see 3GPP TS <NUM>, section <NUM>). The resource for an API contains a "supportedFeatures" attribute of the "SupportedFeatures" data type defined in 3GPP TS <NUM> (see section <NUM>. In one embodiment, UDSF <NUM> may expose the encryption service as part of the UDSF data repository service, such as by registering its encryption capability in NRF <NUM>. NRF <NUM> in turn allows for registration of UDSF <NUM> with additional encryption capability, and allows for discovery of UDSF <NUM> by an NF service consumer <NUM> supporting encryption capability. An NF service consumer <NUM> may therefore select a UDSF <NUM> based on the new encryption service supported by UDSF <NUM> via feature negotiation or NRF discovery. This functionality may be defined as a new UDSF feature for the UDSF data repository service. <FIG> illustrates a supported features data type <NUM> in an illustrative embodiment. The supported features data type <NUM> includes an encryption feature indicator <NUM> that indicates a UDSF <NUM> supports encryption as a service.

<FIG> are message diagrams illustrating the UDSF data repository service in illustrative embodiments. In <FIG>, UDSF <NUM> receives a meta schema <NUM> for records <NUM>. For example, UDSF <NUM> may receive an HTTP PUT from another NF <NUM> (e.g., an Operations, Administration, and Maintenance (OAM) NF, an NF service consumer, etc.) to create or update a meta schema <NUM> for the UDSF data repository service, and stores the meta schema <NUM> in local memory <NUM>. In this example, the meta schema <NUM> includes a tag encryption indicator <NUM> indicating that meta tags <NUM> with the tag name "uePriority" in records <NUM> be encrypted by UDSF <NUM>.

UDSF <NUM> receives a request from an NF service consumer (NF-c <NUM>) for a service operation regarding storage of a record <NUM>. For example, UDSF <NUM> may receive an HTTP PUT from NF-c <NUM> with a record resource to create or update the record <NUM>, to modify the meta <NUM> of a record <NUM>, etc. The request body from the NF-c <NUM> includes meta <NUM> of the record <NUM> in unencrypted format. UDSF <NUM> processes the meta schema <NUM> for the record <NUM> to determine whether meta <NUM> and/or blocks <NUM> are to be encrypted for storage. Based on the meta schema <NUM>, UDSF <NUM> applies encryption to the meta tag <NUM> with the tag name "uePriority" based on the tag encryption indicator <NUM> embedded in the meta schema <NUM>. UDSF <NUM> may leave other data of record <NUM> unencrypted (i.e., other meta tags <NUM> and blocks <NUM>). UDSF <NUM> then stores the record <NUM> with the meta tag <NUM> having the tag name "uePriority" in the encrypted format according to the meta schema <NUM>. UDSF <NUM> also sends a response to NF-c <NUM> with a status code <NUM> OK for the prior request.

Subsequently, UDSF <NUM> receives a request from the same or another NF service consumer (NF-c <NUM>) for a service operation regarding a search of records <NUM> containing certain meta tags <NUM> (i.e., tag name "uePriority") stored in encrypted format. For example, UDSF <NUM> may receive an HTTP GET from NF-c <NUM> requesting a search of records <NUM>. In the example in <FIG>, the request includes filter criteria to search for meta tags <NUM> having the tag name "uePriority", and specifies a comparison value of "medium". UDSF <NUM> may decrypt meta tags <NUM> having the tag name "uePriority", and compare the meta tags <NUM> in unencrypted format with the comparison value "medium". Alternatively, UDSF <NUM> may encrypt the comparison value "medium", and compare the meta tags <NUM> in encrypted format with the encrypted comparison value. UDSF <NUM> may then send a response to NF-c <NUM> containing the search results (not shown).

In <FIG>, UDSF <NUM> receives a meta schema <NUM> for records <NUM>. For example, UDSF <NUM> may receive an HTTP PUT from another NF <NUM> (e.g., an OAM NF, an NF service consumer, etc.) that indicates the meta schema <NUM> for records <NUM>, and stores the meta schema <NUM> in local memory <NUM>. In this example, the meta schema <NUM> includes a block encryption indicator <NUM> indicating that blocks <NUM> of records <NUM> are to be encrypted by UDSF <NUM>.

UDSF <NUM> receives a request from an NF service consumer (NF-c <NUM>) for a service operation regarding storage of a record <NUM>. For example, UDSF <NUM> may receive an HTTP PUT from NF-c <NUM> with a record resource to create or update the record <NUM>, to create or update a block of record <NUM>, etc. The request body from the NF-c <NUM> includes one or more blocks <NUM> of the record <NUM> in unencrypted format. UDSF <NUM> processes the meta schema <NUM> for the record <NUM> to determine whether meta <NUM> and/or blocks <NUM> are to be encrypted for storage. Based on the meta schema <NUM>, UDSF <NUM> applies encryption to the blocks <NUM> based on the block encryption indicator <NUM> embedded in the meta schema <NUM>. UDSF <NUM> may leave the meta <NUM> of record <NUM> unencrypted (i.e., meta tags <NUM>). UDSF <NUM> then stores the record <NUM> with the blocks <NUM> in encrypted format according to the meta schema <NUM>. UDSF <NUM> also sends a response to NF-c <NUM> with a status code <NUM> OK for the prior request.

Subsequently, UDSF <NUM> receives a request from the same or another NF service consumer (NF-c <NUM>) for a service operation regarding retrieval of a record <NUM>, which has blocks <NUM> stored in encrypted format. For example, UDSF <NUM> may receive an HTTP GET from NF-c <NUM> requesting retrieval of the record <NUM>, retrieval of a block <NUM> or all blocks <NUM> of the record <NUM>, etc., as indicated by a "recordId". UDSF <NUM> locates the requested record <NUM>, and decrypts the blocks <NUM> in the requested record <NUM>. UDSF <NUM> then sends a response to NF-c <NUM> with the requested record <NUM> or the requested blocks <NUM> of the record <NUM> in unencrypted format (e.g., <NUM> OK).

In one embodiment, data repository NF <NUM> may comprise or may be implemented in a UDR. <FIG> illustrates a data storage architecture with a UDR <NUM>. UDR <NUM> is an NF configured to provide a UDR data repository service (e.g., Nudr_DataRepository Service) as described in 3GPP TS <NUM> (v17. <NUM><NUM>). UDR <NUM> supports the following functionalities: storage and retrieval of subscription data, storage and retrieval of policy data, storage and retrieval of structured data for exposure, and storage and retrieval of application data. UDR <NUM> acts as an NF service producer <NUM>, and provides the data repository service to an NF service consumer <NUM>. The NF service consumers <NUM> of UDR <NUM> are the UDM <NUM>, PCF <NUM>, and NEF <NUM>, although other NFs may be considered in the future.

In one embodiment, data repository NF <NUM> may comprise or may be implemented in an ADRF. <FIG> illustrates a data storage architecture with an ADRF <NUM>. ADRF <NUM> is an NF configured to provide an ADRF data repository service (e.g., Nadrf DataRepository Service) as described in 3GPP TS <NUM> (v17. <NUM><NUM>). ADRF <NUM> supports the following functionalities: store data or analytics, retrieve data or analytics, and delete data or analytics. ADRF <NUM> acts as an NF service producer <NUM>, and provides the data repository service to an NF service consumer <NUM>. The NF service consumers <NUM> of ADRF <NUM> are a Data Collection Coordination Function (DCCF), a Network Data Analytics Function (NWDAF), and a Messaging Framework Adaptor Function (MFAF), although other NFs may be considered in the future.

Any of the various elements or modules shown in the figures or described herein may be implemented as hardware, software, firmware, or some combination of these.

Also, an element may be implemented as instructions executable by a processor or a computer to perform the functions of the element.

Claim 1:
An apparatus for a data repository Network Function (NF) of a <NUM> core network, comprising means for:
receiving a request from an NF service consumer for a service operation regarding storage of a record, and containing meta and/or one or more blocks of the record;
applying encryption to one or more meta tags of the meta and/or to the blocks of the record based on one or more encryption indicators embedded in a meta schema defined for the meta; and
storing the record with the one or more meta tags and/or the blocks in encrypted format according to the meta schema.