Configuring an element of lawful interception

Abstract

A method for configuring an Element of Lawful Interception, ELI, device (202) in a network function performed by a Lawful Interception, LI, Security Engine, LISE, device (208). The method comprises receiving (304), from the ELI device, a schema request to configure the ELI device, wherein the schema request comprises an ELI identifier and information identifying a type and version of the network function associated with the ELI device; retrieving (306), from an LI Configuration Repository Function, LICREPF (210), a schema identifier based on the information identifying the type and version of the network function; providing (308), to the ELI device, the schema identifier; receiving (312) information identifying an instance of ELI; providing (316), to the ELI device, a list of names of parameters; receiving (320) an indication that the ELI device configuration is complete; and storing (322) information about the ELI device configuration to the LICREPF.

Description

[0001]CONFIGURING AN ELEMENT OF LAWFUL INTERCEPTION TECHNICAL FIELD The disclosure relates to methods for configuring an Element of Lawful Interception(ELI) device in a network function for Lawful Interception (LI). The disclosure alsorelates to network devices configured to perform the same. BACKGROUND European Telecommunications Standards Institute (ETSI) is currently working to specifya new, more secure LI architecture also covering the virtualized environment by takinginto account the latest security standard procedures defined by the ETSI NetworkFunction Virtualization (NFV) Security (SEC) specifications. The new LI Architecture is intended to cover all the LI deployment phases by extending the current standard specifications functionalities scope (limited to the LI operations phases onwards, e.g. X1, HI1 and following X2 / 3, HI2 / 3) to the initial LI phases on the LI Elements instantiation and LI application configuration phases, (ETSI GR NFV-SEC 011 V1.1.1 Network Functions Virtualization (NFV); Security; Report on NFV LI Architecture and 3GPP TS 33.127 V18.6.0 (2023-12-21) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security; Lawful Interception (LI) architecture and functions (Release 18). Specifically, ETSI committees (TC LI and NFV SEC) have recognized the need to specify the X0 interface (described by the references above for the automated configuration of the network elements of lawful interception and for building trust by attestation and setup of the X1 / X2 / X3 interfaces). ETSI TC LI#63 (June 2023) has approved to develop two different Technical Specifications to cover the LI Architecture (ETSI TS 104007 Lawful Interception (LI); LI Architecture V0.0.7) and the X0 internal Interface (ETSI TS 104000 Lawful Interception (LI); Internal Network Interface X0 V0.0.9). SUMMARYAn object of the invention is to enable configuration of network function for lawfulinterception in a communication network where the network function may still have tobe manually configured.A first aspect of the invention relates to a method for configuring an ELI device in anetwork function performed by a network device which comprises a Lawful Interception,LI, Security Engine (LISE) device. The method comprises receiving, from the ELI device,a schema request to configure the ELI device, wherein the schema request comprises an ELI identifier and information identifying a type and version of the network functionassociated with the ELI device; retrieving, from an LI Configuration Repository Function(LICREPF), a schema identifier based on the information identifying the type andversion of the network function; providing, to the ELI device, the schema identifier;receiving, from the ELI device, information identifying an instance of ELI; providing, tothe ELI device, a list of names of parameters; receiving an indication that the ELI deviceconfiguration is complete; and storing information about the ELI device configuration tothe LICREPF.In an embodiment, the method comprises computing one or more parameter values,and the providing of the list of names of parameters comprises providing corresponding parameter values to the list of names of parameters. In an embodiment of the method, each parameter name comprises a corresponding parameter value.In an embodiment, a subset of parameter names has a null parameter value.In an embodiment, the LICREPF does not include a schema identifier associated with the information identifying the type and version of the network function. The methodaccording to this embodiment further comprises: providing, to an operator, a requestfor a schema definition; receiving, from the operator, a schema definition comprising aschema identifier and a list of parameter names and values; storing the schemadefinition to the LICREPF; and providing acknowledgements to the operator and the ELIdevice that the schema definition has been added. The embodiment may also compriseproviding of a request to the ELI device to wait for a schema definition.The method is in an embodiment, comprising: receiving, from the operator, an updaterequest comprising an ELI identifier, a schema identifier, an updated list of parameternames and corresponding updated parameter values; updating a schema definition atthe LICREPF; and providing the updated list of parameter names and correspondingupdated parameter values to the ELI device.A second aspect relates to a network device that implements a LISE device andcomprises a processor configured to cause the network device to perform the methodabove, and optionally according to any of the above embodiments.A third aspect relates to a method for configuring an ELI device in a network function.The method is performed by the ELI device and comprises: providing, to a LISE device,a schema request to configure the ELI device, wherein the schema request comprises an ELI identifier and information identifying a type and version of the network functionassociated with the ELI device; receiving, to the ELI device, the schema identifier;configuring an instance of the ELI based on the schema identifier; providing, to the LISEdevice, information identifying an instance of ELI; receiving, from the LISE device, a listof names of parameters; configuring the instance of the ELI based at least in part onthe list of names of parameters; and providing an indication that the ELI deviceconfiguration is complete.In an embodiment of the method according to the second aspect, the receiving of, fromthe LISE device, the list of names of parameters also comprises receiving correspondingparameter values to the list of names of parameters. Each parameter name maycomprise a corresponding parameter value in this embodiment. One or more parameternames may have a null parameter value in this embodiment, and in such anembodiment the method may further comprise configuration of the instance of the ELIbased at least in part on one or more parameters names that have a non-null parametervalue. In an embodiment the method further comprises: providing the one or moreparameter names that has a null parameter value to an operator; receiving a responsewith parameter values for the one or more parameter names; and configuring theinstance of the ELI with the parameter values received from the operator. In an embodiment of the method of the second aspect, the method further comprises:receiving, from the LISE device, an updated list of parameter names and correspondingupdated parameter values; and providing an update acknowledgement to the LISEdevice.A fourth aspect relates to a network device that implements an ELI device andcomprises a processor configured to cause the network device to perform a methodaccording to the third aspect, and optionally according to any of its aboveembodiments. The information identifying the instance of ELI is in an embodiment of any of the four aspects above, the identifier of the ELI and the schema identifier. The instance of ELI comprises in an embodiment of any of the four aspects above, the identifier of the ELI, the schema identifier, and a list of parameter values.A fifth aspect relates to a computer program, which includes instructions which, whenexecuted by at least one processor of a network device, causes the at least oneprocessor to carry out a method according to the first and third aspects, and optionallyaccording to any of their above embodiments. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.Figure 1 is a block diagram showing a simplified LI architecture according to one ormore embodiments of the present disclosure; Figure 2 is a block diagram showing a X0 service and repository function according to some embodiments of the present disclosure;Figure 3 is a message sequence chart of a method for configuring an ELI device withautomatically computed parameters according to some embodiments of the present disclosure;Figure 4 is a message sequence chart of a method for configuring an ELI device withmanually input parameters according to some embodiments of the present disclosure;Figure 5 is a message sequence chart of a method for configuring an ELI device with ahybrid system of automatically computed parameters and manually input parameters according to some embodiments of the present disclosure; Figure 6 is a message sequence chart of a method for adding a missing schema according to some embodiments of the present disclosure; Figure 7 is a message sequence chart of a method for updating parameter values in according to some embodiments of the present disclosure;Figure 8 is a schematic block diagram of a network device according to someembodiments of the present disclosure; Figure 9 is a schematic block diagram that illustrates a virtualized embodiment of a network node of Figure 6 according to some embodiments of the present disclosure; andFigure 10 is a schematic block diagram of the network device of Figure 6 according tosome other embodiments of the present disclosure. DETAILED DESCRIPTION Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. Network Node: As used herein, a “network node” can be any type of apparatus / device in a core network or any apparatus / device that implements a core network function. Some examples of a core network node include a computer or serverhost for e.g., a Mobility Management Entity (MME), an Access and Mobility Managementfunction (AMF), a Packet Data Network Gateway (P-GW), a Service Capability ExposureFunction (SCEF), a Network Exposure Function (NEF), a Home Subscriber Server (HSS),or the like. Some other examples of a core network node include a node implementing aNetwork Function (NF), Element of Lawful Interception (ELI), a Lawful Interception (LI)Security Engine (LISE), a LI Configuration Repository Function (LICREPF), LI Administration Function (LI ADMF), or the like. In the following description, when stating that any of these functions, such as LISE device or an NF device, perform an action, such as receiving / providing / storing / configuring then it is to be understood that it is in practice the network node / computer / server host / LISE device / NF device that hosts the LISE or NF, respectively, that performs the action. . There currently exist certain challenge(s). ETSI current work items are addressing a completely virtualized network scenarios without detailing any specific Network Function / Elements peculiarity and any intermediate hybrid deployment, e.g. CSPstransition from current part legacy to full virtualized network deployments.Furthermore, ETSI is specifying mainly the macro procedures, leaving out of theTechnical Specifications’ first version publication any specific LI networkfunctions / elements peculiarity in the new full network function virtualization (NFV)network deployment, i.e. correct, whole identification of the vNF / NEs product versions,accurate flow sequencing, etc.The new LI architecture, shown in Figure 1, is being defined by introducing two maintrust domains: Trust Domain A, the customer serving Communication Service Provider (CSP) network, and Trust domain B, which administrates the LI elements in the CSP network. Specifically, the LI architecture of Figure 1 shows some of the involved elements in thenew interception scenarios, but it is essentially focused on the involved relevantfunctional entities, the interfaces, and the attestation phase that guarantees thetrustable of all parties involved once the Network Virtual Function has been created on demand. No characterization of the ELI configuration phase is covered so-far whichshould involve a specific X0 interface between ELI (or any LI service in the Network(NW) domain interfacing ELI from X0) and the Repository Function in the ADMF domain. Such functionalities are still for evaluation and possibly detailed description. Furthermore, the new ETSI TS only focus on cloud native deployments of NFV where virtual functions are automatically allocated on demand. The specifications do not consider hybrid situations where legacy nodes can coexist with cloud native virtualfunction. Such types of hybrid deployments will be more often used in wait for a 5Gtechnology spread in CSP network. Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. For example, the methods disclosed herein provide a solution to configure ELI in the CSP domain including short time deployment scenarios where parts of the network embrace cloud native approach whilst other parts are legacy and still need to be manually configured (e.g. LI policy and parameters pre-configuration). The proposed techniques aim to identify the whole X0 interfacemanageable by an ADMF operator to handle a hybrid network scenario where legacy NF / NE still need to be manually configured by a proper management interface. The same interface may be used also in fully cloud native network function deployment by considering also the day-0 configuration. Certain embodiments may provide one or more of the following technical advantage(s). The methods disclosed herein contribute to ETSI standard for 5G interception by proposing a logic to configure Virtual Network Functions acting as Points of Interception (POIs) in 5G and legacy networks. Current ETSI standard work is focused on the full virtualized network scenarios without considering possible hybrid scenarios development. Another advantage is that a standard solution is provided for both legacy and 5G networks. Additionally, Law Enforcement Agencies (LEA) will have a complete LI standard solution working also for CSP transaction from current scenario development to a completely virtualized one. This reduces the likelihood of interruptions of LI service. ETSI TS 104007 Lawful Interception (LI); LI Architecture V0.0.7 referenced above provides an information flow of the operational high-level steps relevant for LI provisioning and building LI state mainly focusing on attestation phase once one or more new Virtual Network Functions are deployed within the scope of a Network Service. It indicates that warrant provisioning is done just after X0 procedures and ELI attestation. No detail is provided on ELI configuration and related LI specific information.As shown in Figure 2, showing the X0 interface, an ELI device 202 is configured by anX0 service 204 that retrieves the configuration data from an LI ADMF 206 as aControlling Function through an X0 configuration interface 212. Within the LI ADMF 206,the configuration data for each ELI is stored in LI Configuration Repository Function (LICREPF) 210 included in the LISE device 208. The pure configuration X0 interface between ELI device 202 and the LISE device 208 is different from X0 interfaces used for registration (between LISE device 208 and ELI device 202), for certification (between ELI device 202 and LI Certificate Authority (CA)),and for attestation (between ELI and Attest Verification System - AVS). it is explicitlyrecounted that the whole configuration phase is not limited to interface between the ELI(under configuration) and the LISE (x0_c). In an embodiment, a method disclosed herein includes completing X0 interfaces with a further x0 operator (x0_op) interface for LISE repository data managing towards an LI ADMF operator entity (named “operator”). This broad interface is not limited to the pure virtualized network scenario but it guarantees the backward compatibility with current state of art where LI parameters are manually defined by the operator. Such interface is involved also in fully cloud native deployment for node schema configuration and also to notify a request of manual intervention. Additionally, the method may include defining the repository structure inside LISE (unique for all interception network domain types) and the relative business logic involving it. The repository is structured by two parts: a list of schemas based on noderelease and a list of configuration node instance once the LI configuration has beencompleted. The repository data logic involves two sections. The first contains the list of schemas,one for each Virtual Node Function type and related version that are allocated in CSPdomain along with the list of LI parameters to configure. Such parameters are optionalor mandatory and their values are automatically set by ELI or manually filled by theoperator. The list of schemas is defined via x0_op acting as Management Interface at day-0 or during normal operation when a new brand node is needed to be configuredand it is modified according to the CSP network evolution (e.g., the introduction of newVNF). A schema is used for more than one ELI (e.g. in customer network there could betwo Session Border Gateway (SBG) nodes with same SW release and each VNF has its own ELI). The second section of the repository data logic contains the list of schema instances, intended as the list of LI node configuration parameters values once the ELI has been configured. Such settings information is written in the repository by the ELI as full cloud virtual function node via X0 interface or manually by the operator in case of legacy node configuration in hybrid scenario. The proposed X0 interface acts also as a notification channel towards the operator for missing configuration or for any possible errors in repository handling.Schema definitions are added to a LISE device by an operator of an LI ADMF. Theschema is composed by the following elements: schema_ID*, VnfType*, VnfID, where: ^schema_ID: a unique number identifying a schema;^ VnfType: Virtual Network Function Type indicating the type of the VNF that isallocated in the customer network (e.g., SBG, CSCF, …); and ^VnfID: Virtual Network Function ID indicating the VNF version that is allocated inthe customer network (e.g., 15A, 16B, …). Below an example of a possible list of schemas: ^schema_ID*, VnfType*, VnfID^ 1, csf, 14A^ 2, csf, 14B^ 3, msc, 16AThe list of parameters for each schema is composed by the following elements: schema_ID*, parname*, mandatory_flag, legacy_flag where: ^schema_ID: a unique number identifying a schema and it is used to tie theparameter to the schema, ^parname*: a string used to specify the parameter name. The same parametercould be applied to more schemas: e.g. the username parameter is applicable toboth SBG and CSF nodes, ^mandatory_flag: a Boolean flag to indicate if the parameter value is mandatoryor optional, ^legacy_flag: a Boolean flag to indicate if the value of such parameter is intendedto be manually filled by the operator (value “y”) or automatically assigned by the business logic (value “n”) implemented in the ELI. Below some examples of possible schemas with parameters: ^1, x1_addr, mandatory_flag, legacy_flag,^ 1, x2_addr, mandatory_flag, legacy_flag,^ 1, x3_addr, mandatory_flag, legacy_flag,^ 1, x1_port, mandatory_flag, legacy_flag,^ 1, username, mandatory_flag, legacy_flag,^ 1, password, mandatory_flag, legacy_flag,^ 2, x1_addr, mandatory_flag, legacy_flag. According to an LI provisioning information flow in clause 8 of ETSI TS 104007 Lawful Interception (LI); LI Architecture V0.0.7), after initiating a new VNF and being managedattestation, the ELI needs to be configured by selecting the appropriate schema fromthe repository and create an instance of such schema with parameter values. At this stage the configuration procedures may be completed between the LISE repository and the ELI. The second section of the repository contains the list of instances in use. An instance is intended as the allocation of a schema with relative LI parameters values related to the ELI configuration. ELI-(VnfID,VnfType) association is known at step 12 in the LI provisioning flow. The couple VnfID,VnfType is named in the document as VNF_VER since it indicates both node identification and version (e.g. sbg15A, cscf16A…) An instance is composed by: EliID*, schema_ID*, list(parvalues), where: ^EliID: ELI identification associated to the schema;^ schema_ID: the schema identification number used to tie the ELI to the schema;and ^parvalue: the list of parameters’ values; it is manually assigned by the operatoras per legacy fashion via X0 interface acting as configuration management interface or it is assigned by a business logic implemented in LISE according to the parameter type. For example, in the case of IP addresses ELI could assign the value by involving the DHCP server of the region where the VNF has been allocated whilst username and password could be calculated as result of a hash function on schema_ID and parameter name. Different logics are introduced inthe LISE according to any specific new parameter type and considering the network evolution. Moreover, such logic is adjusted according to the introductionof specific parameters different from IP address, username and password. Below is an example of schema instances for the ELI “eli1” associated to schema “1” with parameters’ values: ^eli1, 1, 10.10.10.20, 10.10.10.30, 10.10.10.40, 1234, hash(concat(schema_ID,parname)), hash(concat(schema_ID, parname)) Different scenarios occur based on the availability of the schema in the first repository section and based on the mode where the parameters’ values are calculated (automatically or manually). For example, Figure 3 is a message sequence chart of a method for configuring an ELI device 202 with automatically computed parameters according to some embodiments of the present disclosure. In Figure 3, the schema is found and all parameters are automatically set. Once the attestation phase has been completed, ELI device 202 requests a schema to the LISEdevice towards X0 interface (x0_c). Please note that an operator 302 – ELI device 202interface is a logical interface whose actual deployment is left for implementationdecision (i.e. use x0_c and x0_op). In an embodiment, a connection between theoperator 302 and the ELI device 202 is implemented by means of an X0 connection linkbetween the ELI device 202 and the LI ADMF 206, where the LISE device 208 is a termination point in the LI ADMF 206 during the X0 configuration phase. Once the Schema is found, the ELI device 202 retrieves parameter values that are automaticallycalculated according to a business logic inside the LISE device 208. Once schema hasbeen retrieved with a parameter list and relative values, the ELI device 202 is configured and a new instance is added to the list of instances in the repository. Theinstance is removed from the repository in case of VNF and a related ELI is dismissed.With regard to the steps of the message sequence chart, at step 304, the ELI device202 sends a schema request to the LISE 208 device that includes an ELI identifier andVNF_Ver which includes the VnfID,VnfType as described above. Based on the information, the LISE device 208 retrieves the relevant schema, and sends the response at 308 to the ELI device that includes the schema identifier and the VNF_VER. At 310, the ELI device 202 configures the ELI based on the schema identifier, and at 312 sends an instance request to LISE device 208 with the ELI identifier and theschema identifier. The LISE device 208 computes the parameters’ values at 314 andsends the list of parameter names and corresponding parameter values to the ELI device 202 at 316. The ELI device 202 applies the parameters values to parameters in the schema at step 318 and sends notifications at 320 and 324 that configuration is complete to the LISE device 208 and operator 302 respectively. At 322, the LISE device208 writes the instance to a memory (e.g., the LICREPF 210).Figure 4 is a message sequence chart of a method for configuring an ELI device withmanually input parameters according to some embodiments of the present disclosure.Figure 4 depicts the message sequence chart for the scenario where the schema isfound but instead of automatically applying the parameters, all parameters’ values must be manually provided by the operator towards X0 interface (x0_c). Please note that the“operator” – ELI interface is a logical interface whose actual deployment is left forimplementation decision (i.e. use x0_c and x0_op). ELI functionality must be enriched with the capability to request the parameter value that must be provided by the operator. Once the parameters’ value has been provided, the ELI is configured, and a new instance is added to the list of instances in the repository. The instance is removedfrom the repository in case of a VNF and the related ELI is dismissed.With regard to the steps of the message sequence chart, steps 304-316 of Fig. 4 aresimilar to the corresponding steps of Figure 3, except that when providing the instanceresponse at step 316, in Figure 4, the response includes the list of parameters names, but does not include the parameter values, the parameter value fields are null. The ELI device 202 then at step 402 sends a request to the operator 302 for the parameter values and includes in the request of the list of parameter names for which values are sought. At step 404, the operator 302 provides the response with the parameter values. At step 406, the ELI device 202 configures the ELI with the parameter values, and subsequently, steps 320-324 are performed as in Figure 3. Figure 5 is a message sequence chart of a method for configuring an ELI device with a hybrid system of automatically computed parameters and manually input parameters according to some embodiments of the present disclosure. In this scenario, the schema is found in the repository and some parameters are manually set and others are automatically provided. ELI functionality must be enriched with the capability to request the list of parameters’ values that must be provided by theCSP operator towards X0 interface (x0_c). Please note that the “operator” – ELIinterface is a logical interface whose actual deployment is left for implementation decision (i.e. use x0_c and x0_op). In addition, a new logic is introduced in the LISE device to compute a value according to the parameter type. Once the parameter’s value has been provided, the ELI is configured, and a new instance is added to the list of instances in the repository. The instance is removed from the repository in case of aVNF and related ELI is dismissed.With regard to the steps of Figure 5, the steps 304-316 thereof are similar to thecorresponding steps of Figures 3 and 4, except that when providing the instanceresponse at step 316, in the embodiment illustrated in Figure 5, the response includesthe list of parameters names, but includes the parameter values for only a subset of theparameter names; in the others, the parameter value fields are null. The ELI device 202then requests the parameter values at step 402 for those parameter names that aremissing parameter values, and once the parameters are received at step 404, the ELIdevice 202 configures the schema for the ELI device 202 with the parameters receivedfrom the LISE device 208 and the ELI device 202. Figure 6 is a message sequence chart of a method for adding a missing schema according to some embodiments of the present disclosure. Figure 6 shows the scenario where the schema is not found in the repository and a new one must be defined by the operator. LISE functionality must be enriched with the capability to request a new schema to the operator via X0 interface (x0_c). Please notethat the “operator” – ELI interface is a logical interface whose actual deployment is leftfor implementation decision (i.e. use x0_c and x0_op). The new schema is defined by the operator and appended in the first section of the repository. The operator is informed about the operation completion with a proper ack message from the LISE. At this stage a new instance must be defined according to one of the previous scenarios. With regard to the message sequence chart in Figure 6, at step 304 the ELI device 202 sends the schema request, and at step 306, the LISE device 208 attempts to retrieve the schema but is unsuccessful. The LISE device 208 then requests the schema definition from the operator 302 at step 602, and includes the ELI identifier and the VNF_VER. The LISE device 208 may also optionally send a request to the ELI device 202 to wait (e.g., based on a timer) for the schema. At step 606, the operator 302 provide the schema definition to the LISE device 208 that includes parameter names, and optionally the values, and then the LISE device 208 adds the schema to the repository at step 608 and provides an acknowledgement at step 610 to the operator 302. The LISE device 208 then sends a schema acknowledgement to the ELI device 202 at step 612. Figure 7 is a message sequence chart of a method for updating parameter values in according to some embodiments of the present disclosure; In Figure 7, the parameter is modified in a running instance; the operator 302 provides the new list of parameters’ values to the LISE device 208 that updates both the repository and the value in use by the ELI device 202. For example, at 702, the operator 302 sends a push update to the LISE device 208 that includes the ELI identifier, the schema identifier, and the parameter list of names andcorresponding updated values. The LISE device 208 updates the instance in therepository at step 704, and then sends an update notice to the ELI device 202 with ELI identifier and the parameter list of names and corresponding updated values at step 706. At step 708, the ELI device 202 provides an update acknowledgement to the LISE device 208, and the LISE device 208 at step 710 sends a push update acknowledgement to the operator 302.Figure 8 is a schematic block diagram of a network device / node 800 according to someembodiments of the present disclosure. Optional features are represented by dashedboxes. The network device 800 may be, for example, a network device that implementsall or part of the functionality of the ELI device 202 or LISE device 208 as describedherein, and may in the future thus be a network device according to any futuretelecommunication network standard, such as the emerging 3GPP 6thGenerationnetwork. As illustrated, the network device 800 includes a control system 802 thatincludes one or more processors 804 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and / or the like), memory / computer readable storage medium 806, and a network interface 808. The one or more processors 804 are also referred to herein as processing circuitry. The one or more processors 804 operate to provide one or more functions of a networkdevice 800 as described herein. In some embodiments, the function(s) are implementedin one or more computer programs 810 that are stored, e.g., in the computer readable storage medium 806 and executed by the one or more processors 804. Figure 9 is a schematic block diagram that illustrates a virtualized embodiment of thenetwork device 800 according to some embodiments of the present disclosure. Thisdiscussion is equally applicable to other types of network nodes. Further, other types of network nodes may have similar virtualized architectures. Again, optional features are represented by dashed boxes.As illustrated, in this example, the network device 800 may include the control system802 as described above. The network device 800 includes one or more processingnodes 900 coupled to or included as part of a network(s) 902. If present, the control system 802 is connected to the processing node(s) 900 via the network 902. Each processing node 900 includes one or more processors 904 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory / computer readable storage medium 906, and a network interface 908.In this example, functions 910 of the network device 800 described herein areimplemented at the one or more processing nodes 900 or distributed across the one or more processing nodes 900 and the control system 802 in any desired manner. In some particular embodiments, some or all of the functions 910 of the network device 800 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 900. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 900 and the control system 802 is used in order to carry out at least some of the desired functions 910. In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out thefunctionality of network device 800 or a node (e.g., a processing node 900)implementing one or more of the functions 910 of the network device 800 in a virtualenvironment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).Figure 10 is a schematic block diagram of the network device 800 according to someother embodiments of the present disclosure. The network device 800 includes one ormore modules of ELI device 202 or LISE device 208, each of which is implemented in software. The module(s) ELI device 202 or LISE device 208 provide the functionality ofthe network device 800 described herein. This discussion is equally applicable to theprocessing node 900 of Figure 9 where the modules LI ADMF 206 or NEF device may beimplemented at one of the processing nodes 900 or distributed across multiple processing nodes 900 and / or distributed across the processing node(s) 900 and the control system 802. Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtualapparatuses hosted by a network device, such as the network device 800. Each virtualapparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according to one or more embodiments of the present disclosure. While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.). At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s). Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.

Claims

CLAIMS1. A method for configuring an Element of Lawful Interception, ELI, device (202)in a network function performed by a network device (800) which comprises aLawful Interception, LI, Security Engine, LISE, device (208), the method comprising: receiving (304), from the ELI device (202), a schema request to configure the ELI device (202), wherein the schema request comprises an ELI identifier and information identifying a type and version of the network function associated with the ELI device (202); retrieving (306), from an LI Configuration Repository Function, LICREPF,(210), a schema identifier based on the information identifying the type and version of the network function; providing (308), to the ELI device (202), the schema identifier;receiving (312), from the ELI device (202), information identifying an instanceof ELI; providing (316), to the ELI device (202), a list of names of parameters;receiving (320) an indication that the ELI device configuration is complete; and storing (322) information about the ELI device configuration to the LICREPF.

2. The method of claim 1, wherein the method further comprises:computing (314) one or more parameter values, and the providing (316) the list of names of parameters further comprises providing corresponding parameter values to the list of names of parameters.

3. The method of claim 1, wherein each parameter name comprises acorresponding parameter value.

4. The method of claim 1, wherein a subset of parameter names has a nullparameter value.

5. The method of claim 1, wherein the LICREPF (210) does not include aschema identifier associated with the information identifying the type and version of the network function, the method further comprises: providing (602), to an operator (302), a request for a schema definition;receiving (606), from the operator (302), a schema definition comprising a schema identifier and a list of parameter names and values; storing (608) the schema definition to the LICREPF (210); and providing (610, 612) acknowledgements to the operator (302) and the ELIdevice (202) that the schema definition has been added.

6. The method of claim 5, further comprising:providing (604) a request to the ELI device (202) to wait for a schema definition.

7. The method of any one of claims 1 to 6, further comprising:receiving (702), from the operator (302), an update request comprising an ELI identifier, a schema identifier, an updated list of parameter names and corresponding updated parameter values; updating (704) a schema definition at the LICREPF (210); and providing (706) the updated list of parameter names and corresponding updated parameter values to the ELI device (202).

8. The method according to any one of the preceding claims, wherein theinformation identifying the instance of ELI is the identifier of the ELI and the schemaidentifier.

9. The method according to any one of the preceding claims, wherein the instanceof ELI comprises the identifier of the ELI, the schema identifier, and a list ofparameter values.

10. A network device (800) that implements a Lawful Interception, LI, Security Engine, LISE, device (208) and comprises a processor (804) configured to cause thenetwork device (800) to perform a method according to any one of claims 1 to 9.

11. A method for configuring an Element of Lawful Interception, ELI, device (202)in a network function performed by a network device (800) which comprises the ELIdevice (202), the method comprising: providing (304), to a Lawful Interception, LI, Security Engine, LISE, device (208), a schema request to configure the ELI device (202), wherein the schema request comprises an ELI identifier and information identifying a type and version of the network function associated with the ELI device (202); receiving (308), to the ELI device (202), the schema identifier; configuring (310) an instance of the ELI based on the schema identifier; providing (312), to the LISE device (208), information identifying an instanceof ELI; receiving (316), from the LISE device (208), a list of names of parameters; configuring (318, 406) the instance of the ELI based at least in part on the list of names of parameters; and providing (320, 324) an indication that the ELI device configuration is complete.

12. The method of claim 11, wherein the receiving (316), from the LISE device(208), the list of names of parameters also comprises receiving corresponding parameter values to the list of names of parameters.

13. The method of claim 12, wherein each parameter name comprises acorresponding parameter value.

14. The method of claim 12, wherein one or more parameter names has a nullparameter value.

15. The method of claim 14, further comprising:configuring (318) the instance of the ELI based at least in part on one or more parameters names that have a non-null parameter value.

16. The method of any one of claims 14 and 15, further comprising:providing (402) the one or more parameter names that has a null parameter value to an operator (302); receiving (404) a response with parameter values for the one or moreparameter names; and configuring (406) the instance of the ELI with the parameter values received from the operator (302).

17. The method of any one of claims 11 to 16, further comprising:receiving (706), from the LISE device (208), an updated list of parameternames and corresponding updated parameter values; and providing (708) an update acknowledgement to the LISE device (208).

18. The method according to any one of claims 11-17, wherein the information identifying the instance of ELI is the identifier of the ELI and the schema identifier.

19. The method according to any one of claims 11-17, wherein the instance of ELI comprises the identifier of the ELI, the schema identifier, and a list of parameter values.

20. A network device (800) that implements an Element of Lawful Interception,ELI, device (202) and comprises a processor (804) configured to cause the networkdevice (800) to perform a method according to any one of claims 11 to 19.

21. A computer program (810) including instructions which, when executed by atleast one processor (804) of a network device (800), causes the at least oneprocessor to carry out a method according to any one of claims 1-9 or 11-19.

Images