Content for TS 33.127 Word version: 18.8.0

0… 5… 5.4… 5.6… 5.7… 6… 6.2.2… 6.2.3… 6.2.5… 6.3… 6.3.3… 6.3.4… 6.4… 7… 7.3… 7.4… 7.4.7… 7.5… 7.6… 7.7… 7.8… 7.9… 7.10… 7.11… 7.12… 7.13… 7.14… 7.15… 7.16… 8… A… A.2… A.3… A.4… B… D… E…

5.6 LI in a virtualised environment 5.6.1 General 5.6.2 Virtualised deployment architecture 5.6.3 LI function instantiation and lifecycle management procedures 5.6.3.1 Controller virtualisation layer and MANO procedures 5.6.3.1.1 Responsibilities 5.6.3.1.2 General procedures 5.6.3.1.3 Instantiation 5.6.3.1.4 Modification 5.6.3.1.5 Termination 5.6.3.1.6 Direct instantiation of LI Functions by ADMF 5.6.3.2 LI_X0 procedures 5.6.3.3 Exception Procedures
...

5.6 LI in a virtualised environment p. 34

5.6.1 General p. 34

Virtualisation is one of the 3GPP network deployment options for NFs containing LI functions as described in the present document. In virtualised deployments, many of the initial deployment and configuration actions performed manually in non-virtualised deployments need to be automated and occur in near real-time. This clause outlines the basic architecture enhancements to support virtualised LI in 3GPP networks. Security aspects relating to virtualisation are described in clause 8.

The architecture enhancements in this clause are intended to apply to any virtualised 2G, 3G, 4G, 5G scenario including IMS that needs to support LI. Where legacy network functions defined in TS 33.107 are virtualised, the architecture in Figure 5.6-1 shall be applied, with legacy TS 33.107 reference points and functional elements substituted for their equivalent in the present document (e.g. POI is equivalent to ICE and LI_X2 is equivalent to X2 in TS 33.107).

5.6.2 Virtualised deployment architecture p. 34

Figure 5.6-1 shows the necessary extensions to the basic LI architecture described in clause 5.2 required to support real-time deployment of virtualised LI functions. Figure 5.6-1 is a simplified version of the virtual LI function deployment procedures.

Copy of original 3GPP image for 3GPP TS 33.127, Fig. 5.6-1: Simplified virtualised LI system with provisioning infrastructure for a direct provisioned POI

Figure 5.6-1: Simplified virtualised LI system with provisioning infrastructure for a direct provisioned POI
(⇒ copy of original 3GPP image)

Figure 5.6-1 shows the LI NFV controller and NFV Management and Orchestration functions (MANO), together with two logical interfaces:

LI_NO: This interface allows to exchange correlation and notification information between the LI application/service and NFV layer about related VNF and VNFC lifecycle management; it also allows to configure optional virtual deployment parameters. In addition, in case of LI functions not instantiated by OSS/BSS (see clause 5.6.3.1.6 of the present document) this interface shall support LI function instantiation requests from the ADMF.
LI_MANO: This interface allows to notify the LI NFV controller about VNF/VNFC lifecycle management and enforce virtual deployment LI security policy.

These two interfaces are assumed to be already setup between the involved functional entities via a mutual authenticated and encrypted dedicated connection.

The procedures in clause 5.6.3 assume that the LIPF, LICF and NFV LI Controller already exist before creation of any other LI functions.

The OSS/BSS is responsible for controlling the number of 3GPP VNFs and service chains within the network. The OSS/BSS instructs NFV MANO to instantiate, scale or terminate one or more VNFs. NFV MANO is also able to instantiate and terminate VNF sub-components (VNFCs) dynamically without input from the OSS/BSS in order to maintain performance and resilience requirements. This is especially likely in container-based implementations.

To ensure that all LI related aspects, if applicable, are considered within that VNF, NFV MANO notifies the LI NFV Controller about the VNF and VNFC instantiation, scaling and termination. In case where a VNF, about to be instantiated, is expected to have LI specific functionalities such as POI, TF or MDF, the LI NFV controller notifies the LIPF about those LI specific functionalities within the VNF. The LIPF would forward that notification to the LICF, which in turn, validate/verify/authorize (via LIPF, of course) that POI/TF/MDF for LI over LI_X0. If the VNF does not contain an LI function then the LI NFV Controller may still notify the LIPF/LICF.

LI NFV Controller shall be configurable to apply default LI policy and configuration to LI VNFCs without explicit authorisation from the LIPF/LICF, depending on network performance and LI security requirements. The LI NFV Controller shall be able to apply policy on a per instantiation basis or apply a static configuration policy to NFV MANO, which NFV MANO is able to use to automatically instantiate LI components using this default configuration.

In most deployments some default LI configuration information will need to be provided as part of the VNF image packages and package descriptor files. Such LI information needs to be adequately protected within NFV MANO and software catalogues.

Where explicit authorisation of LI components is required, the LIPF would notifies the LI NFV Controller that the LI specific functions are authorized/verified and the LI NFV Controller notifies NFV MANO.

5.6.3 LI function instantiation and lifecycle management procedures p. 35

5.6.3.1 Controller virtualisation layer and MANO procedures p. 35

5.6.3.1.1 Responsibilities p. 35

The 5G NRF is not involved in the discovery of LI functions, as described in clause 5.3.6. NFs containing LI functions shall only be discoverable by the NRF / SIRF once all LI initialisation steps in this clause have been completed and the OSS/BSS/ MANO informed that LI operation is ready. The process by which the NRF / SIRF is notified by the OSS/BSS/MANO is out of scope of the present document.

5.6.3.1.2 General procedures p. 35

When the 3GPP network OSS/BSS makes a request to NFV MANO to instantiate, modify or terminate a 3GPP NF, NFV MANO shall notify the LI NFV Controller of the request over LI_MANO using procedures as described in ETSI GS NFV-IFA 026 [20] or equivalent. The NFV LI Controller shall be able to send all applicable NF changes to the LIPF over LI_NO, so that the LICF is able to maintain an understanding of network topology. In 5G, the LICF in the ADMF (via the LIPF) also maintains understanding of active use of NF via the NRF / SIRF.

In addition, NFV MANO is required to send notifications of non-OSS/BSS triggered (e.g. NFV MANO automated VNF relocation, or software image update) as described in ETSI GS NFV IFA 026 [20]. The LI NFV Controller shall also be able to provide applicable notifications to the LICF in the ADMF (via the LIPF) of such changes.

In deployments where the implementation supports data centre / location verification for NFs being instantiated or modified, subject to operator policy the LI NFV Controller shall not allow instantiation or modification of LI functions or associated NFs which do not comply with LI location constraints set by the LICF in the ADMF (via the LIPF).

5.6.3.1.3 Instantiation p. 36

Where an NF being instantiated contains one or more LI functions (e.g. POI, TF, MDF) the LI NFV Controller shall handle any necessary steps to allow the LI functions to be instantiated by NFV MANO and the LI functions to be added to the LI environment, so that initial contact between the LI functions and the LIPF in the ADMF can be established. The LI NFV Controller shall provide details of the new LI functions to the LICF in the ADMF (via the LIPF), including the identity of the new LI functions, so that the LICF is aware of the existence of the LI functions.

In deployments where ADMF (LICF) signing of LI function software images has been implemented, the LI NFV Controller shall provide the signatures to the LICF in the ADMF (via the LIPF) for verification and shall only authorise NFV MANO to continue instantiation of the LI function if the LICF has successfully verified the signatures.

5.6.3.1.4 Modification p. 36

When an NF containing LI functions is being modified (e.g. scaled or relocated) the LI NFV Controller shall manage the necessary interactions with NFV MANO (using the procedures in ETSI GS NFV-IFA 026 [20] or equivalent) to allow the LI functions to also be modified in alignment with changes to their parent NF. The LI NFV Controller shall notify the LICF in the ADMF via the LIPF over LI_NO, of the subsequent modifications. Where the modifications result in a new LI function being instantiated (e.g. where a scale up exceeds the existing capabilities of the existing LI functions and a new VNFC is instantiated), the LI NFV Controller shall notify the LICF about the existence of the new LI function and indicate to which existing NF the new LI function is associated.

5.6.3.1.5 Termination p. 36

When an NF containing LI functions is terminated, the LI NFV Controller shall manage the necessary interactions with NFV MANO (using the procedures in ETSI GS NFV IFA 026 [20] or equivalent) and notify the LICF via the LIPF that the LI functions have been removed from the system. The LICF in the ADMF shall ensure that certificates associated with those LI functions are appropriately revoked.

5.6.3.1.6 Direct instantiation of LI Functions by ADMF p. 36

Procedures in clauses 5.6.3.1.3, 5.6.3.1.4 and 5.6.3.1.5 are based on the OSS/BSS being responsible for creating all LI functions as part of normal network operations (e.g. LI functions are embedded VNFC within a VNFs or are instantiated as part of network service descriptors where a whole slice or large set of VNFs are instantiated together as part of a complete network service).

In some scenarios, the ADMF needs to create specific virtualised LI functions (e.g. MDF) within the NFVI used to host other operator NFs but for security reasons requires that the OSS/BSS does not manage or have knowledge of these. In this scenario, the LICF, instructs the LI NFV Controller via LIPF over LI_NO to request NFV MANO via LI_MANO to instantiate an LI specific image. This LI VNF may either be inserted as part of an existing network service chain or create a new LI specific service chain.

In such scenarios, the ADMF shall play the role of the OSS/BSS and the LI_NO interface shall support the related operations; the LIPF should implement the equivalent logic of OSS/BSS for these operations.

5.6.3.2 LI_X0 procedures p. 37

Only once an LI function has been instantiated and the LIPF in the ADMF informed of that NF's existence, can that NF be managed by the LIPF in the ADMF over LI_X0. Such notification is achieved as described in clause 5.6.3.1 over LI_NO and LI_MANO and occurs prior to any SIRF/NRF (or equivalent) NF discovery processes.

The LI_X0 interface is used to manage LI functions after instantiation such they are made ready for LI use and subsequent provisioning over LI_X1.

After a VNF is instantiated (e.g. using the procedures in ETSI GR NFV-SEC 011 [10] and ETSI NFV-IFA 026 [20] or equivalent), it is necessary to automatically configure the LI functions (e.g. POI, TF, MDF) before use (i.e. to initialise it to a state where it can accept LI_X1 messages). To achieve this the LI Function shall after instantiation and initial network configuration by NFV MANO (e.g. allocation of network IP address and FQDN) contact the LIPF over the LI_X0 interface and LIPF will notify the LICF that a new potential LI function has contacted the LIPF. The LIPF shall only accept incoming connections from new LI functions that have previously been notified to the LIPF/LICF by the LI NFV controller over LI_NO. The LI_NO interface shall carry information to allow the LIPF to associate a VNF instance with the LI application instance running in it.

The LICF in the ADMF, through the LIPF, shall verify the authenticity of the LI function over LI_X0 in order to verify that the new LI function has been instantiated from a valid software image. If the LI function software image has been partly encrypted as described in ETSI GR NFV-SEC 011 [10], then once the LICF has verified the integrity of the LI function it shall provide any necessary keys to the LIPF to decrypt the LI function to complete instantiation of that LI function.

Once a trust relationship has been established between the LICF and new LI function, the LIPF shall issue the LI function with an LI identity (e.g. POI CSCF number 42 or LI System FQDN) and provide the other necessary certificates and configuration information to allow the new LI function to be configured for LI use on LI_X1. The LICF is responsible for providing necessary information and policy rules necessary for the LIPF to perform configuration of LI functions over LI_X0. For the purposes of instantiation IEFs and ICF follow the same instantiation flow as POIs except that the LIPF has a more limited role in managing these functions after instantiation over LI_XEM1 compared to POIs as neither of these types of LI functions are subject to LI provisioning.

In the case of triggered POIs which are not directly provisioned by the LIPF in the ADMF over LI_X1, the LIPF is still responsible for LI_X0 configuration of the POI including identity manage and all necessary identity / communication certificates in order to allow the POIs and TF to communicate over LI_X1, LI_T2 and LI_T3. The same applies to virtualised MDFs or CC-PAG.

Once an LI function directly associated with or embedded in an NF has been made fully ready for provisioning over LI_X1 using LI_X0, the LICF in the ADMF via the LIPF shall notify the LI NFV Controller that the LI function is ready for service and NFV MANO may advise the OSS/BSS that the NF associated with the LI functions is ready for service and discovery by the NRF. For MDFs, CC-PAGs, or non-embedded POIs the LICF may still need to provide a ready for service indication to NFV MANO / OSS / BSS depending on the implementation scenario.

During normal system operation LI_X0 shall be used by the LIPF in the ADMF to maintain the LI function throughout the LI function's lifecycle, except as a result of scaling or other changes applied by NFV MANO (such changes are first managed by the NFV LI Controller through LI_NO and LI_MANO and any necessary LI_X1/LI_X2/LI_X3 level re-configuration then applied over LI_X0). In-life certificate updates, identity changes, LI_X1/2/3 credential changes and other similar configuration changes shall be supported by both the LIPF in the ADMF and LI functions over LI_X0.

Figure 5.6-2 shows an example of what the procedures described in this clause look like when instantiating a new NF and associated LI functions.

Copy of original 3GPP image for 3GPP TS 33.127, Fig. 5.6-2: Example simplified flow-diagram for OSS / BSS originated LI instantiation procedures

Figure 5.6-2: Example simplified flow-diagram for OSS / BSS originated LI instantiation procedures
(⇒ copy of original 3GPP image)

5.6.3.3 Exception Procedures p. 38

If during normal LI system operation the ADMF (LIPF or LICF) detects or is informed of abnormal LI function behaviour, then subject to operator policy the LICF in the ADMF via the LIPF shall be able via the LI NFV Controller over LI_NO and LI_MANO to request immediate termination or quarantine of the LI function to NFV MANO as defined in ETSI GS NFV-IFA 026 [20]. For this purpose, the LI NFV Controller acts as a Semi-Active SM as described in ETSI GS NFV-IFA 026 [20].

If during normal operation the LICF in the ADMF via the LIPF is notified of a NF modification or instantiation event which does not comply with operator LI policy (e.g. NF location is not within allowed locations or LI functionality is not authorised for a given deployment scenario) the LICF via the LIPF shall be able to deny NFV MANO and the OSS/BSS authorisation to complete the system change. The ADMF shall be able to delegate responsibility for real-time termination handling to the NFV LI Controller. The NFV LI Controller shall be responsible for reporting detected events and subsequent actions taken by LI NFV Controller and NFV MANO to the LICF via the LIPF over LI_NO.