Content for TS 28.510 Word version: 17.0.0
6 Specification level requirements
6.1 Requirements
6.2 Actor roles
6.3 Telecommunication resources
6.4 Use cases
$ Change history
6 Specification level requirements p. 9
6.1 Requirements p. 9
6.1.1 Requirements for Itf-N p. 9
REQ-NFV_CM_Itf-N-FUN-1
The IRPAgent shall support the capability allowing IRPManager to manage the mobile networks that include virtualized network functions.
REQ-NFV_CM_Itf-N-FUN-2
The IRPAgent shall support the capability allowing IRPManager to differentiate the virtualized and non-virtualized network functions.
REQ-NFV_CM_Itf-N-FUN-3
IRPAgent shall support the capability to allow IRPManager to create the MOI(s) corresponding to a VNF instance (application part) and configure the attribute(s) of the MOI(s).
REQ-NFV_CM_Itf-N-FUN-4
IRPAgent shall support the capability to notify IRPManager of the completion of the MOI(s) creation and configuration.
REQ-NFV_CM_Itf-N-FUN-5
IRPAgent shall support the capability to allow IRPManager to delete the MOI(s) corresponding to a VNF instance (application part).
REQ-NFV_CM_Itf-N-FUN-6
IRPAgent shall support the capability to allow IRPManager to update the Managed Object instance(s) corresponding to a VNF instance (application part).
REQ-NFV_CM_Itf-N-FUN-7
IRPAgent shall support the capability to notify IRPManager the change of the Managed Object instance(s) corresponding to a VNF instance (application part).
REQ-NFV_CM_Itf-N-FUN-8
IRPAgent shall support the capability to allow IRPManager to set the MOI(s) to associate with a VNF instance (application part) and configure the attribute(s) of the MOI(s).
REQ-NFV_CM_Itf-N-FUN-9
IRPAgent shall support a capability allowing IRPManager to request enabling/disabling the auto-scaling of the VNF instance(s) corresponding to an NE.
6.1.2 Requirements for Os-Ma-nfvo p. 10
None.
6.1.3 Requirements for Ve-Vnfm-em p. 10
None.
6.1.4 Requirements for Ve-Vnfm-vnf p. 10
None.
6.2 Actor roles p. 10
See detailed actors and roles for each use case in clause 6.4.
6.3 Telecommunication resources p. 10
See detailed telecommunication resources for each use case in clause 6.4.
6.4 Use cases p. 10
6.4.1 MOI creation related use cases p. 10
6.4.1.1 Introduction p. 10
The MO instance and VNF instance can exist independently. The 3GPP management system maintains the unidirectional relationships (MOI points to VNF instance) between MO instances and the corresponding VNF instances.
There are following potential scenarios to maintain the relationship between MO instances and VNF instances.
Scenario 1:
The NM initiated MO instance creation operation (a new version of create MO operation) over Itf-N provides the available VNF instance identifier as an input parameter. The created MO instance representing vNE has the relationship with the selected VNF instance.
Scenario 2:
The NM initiated MO instance creation operation (a new version of create MO operation) over Itf-N has a parameter indicating whether a new VNF needs to be instantiated by EM. The presence of the indicator triggers the VNF instantiation request from EM to VNFM. The created MO instance representing vNE has the relationship with the new created VNF instance.
Scenario 3:
NM initiates MO instance creation operation using existing create MO operation over Itf-N. NM initiates the VNF instantiation operation via Os-Ma-nfvo. NM sets the relationship between MO instance representing vNE and VNF instance by SetMOAttribute operation (in Bulk or Basic CM IRP).
Scenario 4:
NM initiates the VNF instantiation operation via Os-Ma-nfvo. After the VNF instantiation is complete, the vNE starts execution and informs its presence to EM.
EM would then create the MOI(s) representing the vNE. EM populates this newly created MOI with VNF identifier received from vNE. EM then notifies NM that the MOI(s) representing the newly installed vNE is created. NM can now exercise CM related operations on the said MOI from now on.
Scenario 5:
NM requests (conveyed via the Bulk CM IRP file) EM to create a set of MOI(s) representing a set of vNE.
EM would initiate necessary VNF instantiation operations towards VNFM. After a VNF instantiation is complete, the vNE starts execution and informs its presence to EM.
EM would then create the MOI(s) representing the vNE. EM populates this newly created MOI with VNF identifier received from vNE. EM then notifies NM that the MOI(s) representing the newly installed vNE is created. NM can now exercise CM related operations on the said MOI from now on.
6.4.1.2 Create MOI(s) after a VNF is instantiated (Triggered by NM) p. 11
| Use Case Stage | Evolution/Specification | <<Uses>> Related use |
|---|---|---|
| Goal | Create the MOI(s) corresponding to a VNF instance (application part) and configure the attribute(s) of the MOI(s) after the VNF is instantiated. | |
| Actors and Roles | 3GPP NM. | |
| Telecom resources | 3GPP NM, 3GPP EM, NFVO | |
| Assumptions | ||
| Pre-conditions | The MOI(s) for the subject VNF instance have not been created. | |
| Begins when | NM receives the message indicating the subject VNF has been instantiated from NFVO or EM. | |
| Step 1 (M) | NM sends a request to EM to create the MOI(s) corresponding to the subject VNF instance (application part) and configure the attribute(s) of the MOI(s). | |
| Step 2 (M) | EM creates the MOI(s) corresponding to the subject VNF instance (application part). | |
| Step 3 (M) | EM configures the attribute(s) of the created MOI(s). | |
| Step 4 (M) | EM notifies NM of the completion of the MOI(s) creation and configuration. | |
| Ends when | Ends when all steps identified above are completed or when an exception occurs. | |
| Exceptions | One of the steps identified above fails. | |
| Post-conditions | The MOI(s) corresponding to a VNF instance (application part) is/are created and configured. | |
| Traceability | REQ-NFV_CM_Itf-N-FUN-3, REQ-NFV_CM_Itf-N-FUN-4 |
6.4.1.3 Create MOI(s) after a VNF is instantiated (Triggered by EM) p. 11
| Use Case Stage | Evolution/Specification | <<Uses>> Related use |
|---|---|---|
| Goal | Create the MOI(s) corresponding to a VNF instance (application part) and configure the attribute(s) of the MOI(s) after the VNF is instantiated. | |
| Actors and Roles | 3GPP EM. | |
| Telecom resources | 3GPP EM, VNFM | |
| Assumptions | ||
| Pre-conditions | The MOI(s) for the subject VNF instance have not been created. | |
| Begins when | EM receives the message indicating the VNF has been instantiated from VNFM; | |
| Step 1 (M) | EM creates the MOI(s) corresponding to the subject VNF instance (application part). | |
| Step 2 (M) | EM configures the attribute(s) of the created MOI(s). | |
| Step 3 (M) | EM notifies NM of the completion of the MOI(s) creation and the VNF configuration. | |
| Ends when | Ends when all steps identified above are completed or when an exception occurs. | |
| Exceptions | One of the steps identified above fails. | |
| Post-conditions | The MOI(s) corresponding to a VNF instance (application part) is/are created and configured. | |
| Traceability | REQ-NFV_CM_Itf-N-FUN-4 |
6.4.1.4 Create MOI(s) for a specified VNF instance (Triggered by NM) p. 12
| Use Case Stage | Evolution/Specification | <<Uses>> Related use |
|---|---|---|
| Goal | Create the MOI(s) corresponding to an existing VNF instance (application part) and configure the attribute(s) of the MOI(s) after the VNF is instantiated if needed. | |
| Actors and Roles | 3GPP NM. | |
| Telecom resources | 3GPP NM, 3GPP EM, NFVO | |
| Assumptions | ||
| Pre-conditions | The MOI(s) for the subject specified VNF instance have not been created. NM receives the message indicating the subject VNF has been instantiated. | |
| Begins when | Operator decides to create MOI(s) for an existing VNF instance. | |
| Step 1 (M) | NM sends a request to EM to create the MOI(s) with the VNF instance identifier and configure the attribute(s) of the MOI(s). | |
| Step 2 (M) | EM creates the MOI(s) and sets the relevant MOI(s) attributes with the VNF instance identifier. | |
| Step 3 (O) | EM may configure other attribute(s) of the created MOI(s) if needed. | |
| Step 4 (M) | EM notifies NM of the completion of the MOI(s) creation and configuration. | |
| Ends when | Ends when all steps identified above are completed or when an exception occurs. | |
| Exceptions | One of the steps identified above fails. | |
| Post-conditions | The MOI(s) corresponding to an existing VNF instance (application part) is/are created and configured. | |
| Traceability | REQ-NFV_CM_Itf-N-FUN-3, REQ-NFV_CM_Itf-N-FUN-4 |
6.4.1.5 Associate MOI(s) with a VNF instance (Triggered by NM) p. 12
| Use Case Stage | Evolution/Specification | <<Uses>> Related use |
|---|---|---|
| Goal | Associate MOI(s) with a VNF instance and configure the attribute(s) of the MOI(s) if needed. | |
| Actors and Roles | 3GPP NM. | |
| Telecom resources | 3GPP NM, 3GPP EM | |
| Assumptions | NM has subscribed to the attributeValueChange notification. | |
| Pre-conditions | The corresponding VNF instance has been instantiated and the VNF instance identifier has been notified to NM. The MOI(s) has been created. | |
| Begins when | Operator decides to associate MOI(s) with an existing VNF instance. | |
| Step 1 (M) | NM sends a request with the VNF instance identifier to EM to associate MOI(s) with the VNF instance identified by the identifier. The other configuration parameters are also included in the request if needed. | |
| Step 2 (M) | EM sets the attributes of the created MOI(s) with the VNF instance Identifier. | |
| Step 3 (M) | EM responds NM of the completion of the association of MOI(s) and VNF instance. | |
| Ends when | Ends when all steps identified above are completed or when an exception occurs. | |
| Exceptions | One of the steps identified above fails. | |
| Post-conditions | The MOI(s) corresponding to the specified VNF instance is/are created. | |
| Traceability | REQ-NFV_CM_Itf-N-FUN-8 |
6.4.1.6 Bulk MOIs creation p. 13
| Use Case Stage | Evolution/Specification | <<Uses>> Related use |
|---|---|---|
| Goal | To deploy large number of network elements whose software components are designed to run on NFVI. (The term NE used in this UC refers to network elements whose software components are designed to run on NFVI.) | |
| Actors and Roles | NM | |
| Telecom resources | EM, NFVO, network planned data. | |
| Assumptions | Operator has the network planned data for NEs and is ready for their deployment. The planned data contains information about the to-be-deployed NEs.
During the VNF instantiation process, the VNF:
| |
| Pre-conditions | For each wanted NE, operator knows the number and the types of VNFs needed. EM would keep records of all incoming messages that bear VNF ID and the VNF address (see Step 6). | |
| Begins when | Operator decides to deploy the NEs of specified types.
Operator constructs a "Bulk Configuration Data File" (File) [see clause 10 of [9]] that captures
| |
| Step 1 (M) | Operator instructs NM to deploy the planned NEs using information of the File. | |
| Step 2 (M) | NM, based on information in the File and the knowledge described in Pre-conditions, requests NFVO to instantiate all VNF(s) required for the deployment of all NEs wanted [Note 1.] NFVO, using VNFM/VIM, instantiates the VNFs requested for instantiation and responds to NM with the VNF IDs of the successfully instantiated VNFs [Note 1]. | |
| Step 3 (M) | NM updates the File by capturing:
| |
| Step 4 (M) | NM transfers the File (see procedure in [9]) to EM to deploy the planned network in accordance to the File information. | |
| Step 5 (M) | EM creates sets of MOIs (where one set corresponds to one NE) in its Management Information Base (MIB) in accordance to the File information. The MOIs' vnfIdList attributes has the corresponding VNF IDs as values. The NE attribute operation state is set to Disabled. | |
| Step 6 (M) | When a VNF is instantiated, it knows its managing EM address (because of assumption a, b or c). VNF sends a message that bear its VNF ID and its VNF address, to its managing EM. | |
| Step 7 (M) | EM examines its records (see Pre-condition) or on reception of message from VNF that bears the VNF ID and the VNF address, will try to identify if the MOI(s) whose vnfIdList has an vnfId that is same as the VNF ID received. When found, the EM considers that the VNF is running on NFVI. When all VNF instance(s) of a NE are running on NFVI, the operation state of the NE is changed to Enabled. EM notifies NM of the NE whose operation state is Enabled. | |
| Ends when | The above steps have successfully completed. | |
| Exceptions | -- | |
| Post-conditions | The network resource model instance tree, maintained by EM, corresponding to the information of the File is created and the state of all NE(s) are Enabled. | |
| Traceability | REQ-NFV_CM-CON-10 | |
|
NOTE 1:
NM may issue InstantiateNsRequest (clause 7.3.3. [8]) to NFVO or issue UpdateNsRequest to NFVO with input parameter updateType==instantiateVnf (clause 7.3.5 of [8]), based on his knowledge of NS instances in existence.
NOTE 2:
It is assumed that MOIs would have an attribute called vnfListId whose elements are identifier of VNF instance involved.
|
||
6.4.2 Configure VNF instance with Managed Object attributes p. 14
| Use Case Stage | Evolution/Specification | <<Uses>> Related use |
|---|---|---|
| Goal | Configure an existing VNF instance with Managed Object attributes. | |
| Actors and Roles | IRPManager | |
| Telecom resources | ||
| Assumptions | ||
| Pre conditions | The MOI(s) for the NE have been created. | |
| Begins when | Operator decides to configure Managed Object attributes for an existing VNF instance. | |
| Step 1 (M) | IRPManager sends a request to IRPAgent to configure the VNF instance over Itf-N. | |
| Step 2 (M) | IRPAgent configures the VNF instance with Managed Object attributes. | |
| Step 3 (M) | IRPAgent returns the result of the VNF instance configuration to IRPManager over Itf-N. | |
| Ends when | Ends when all mandatory steps identified above are successfully completed or when an exception occurs. | |
| Exceptions | One of the steps identified above fails. | |
| Post Conditions | The VNF instance has been configured with Managed Object attributes. | |
| Traceability | REQ-NFV_CM_Itf-N-FUN-6 |
6.4.3 Delete the MOI(s) corresponding to a VNF instance (application part) p. 15
| Use Case Stage | Evolution/Specification | <<Uses>> Related use |
|---|---|---|
| Goal | Delete the MOI(s) corresponding to the subject VNF instance (application part). | |
| Actors and Roles | 3GPP NM | |
| Telecom resources | 3GPP NM, 3GPP EM | |
| Assumptions | ||
| Pre-conditions | The 3GPP services provided by the VNF instance where its relevant MOI(s) are to be deleted have been released | |
| Begins when | The operator decides to delete the MOI(s) corresponding to a VNF instance (application part). | |
| Step 1 (M) | NM sends a request to EM to delete the MOI(s) corresponding to the subject VNF instance (application part). | |
| Step 2 (M) | EM deletes the MOI(s) corresponding to the subject VNF instance (application part). | |
| Step 3 (M) | EM notifies NM of the completion of the MOI(s) deletion. | |
| Ends when | Ends when all steps identified above are completed or when an exception occurs. | |
| Exceptions | One of the steps identified above fails. | |
| Post-conditions | The MOI(s) corresponding to the subject VNF instance (application part) are deleted. | |
| Traceability | REQ-NFV_CM_Itf-N-FUN-5. |
6.4.4 Update the MOI(s) corresponding to the subject VNF instance (application part) after a VNF instance is scaled (Triggered by NM) p. 15
| Use Case Stage | Evolution/Specification | <<Uses>> Related use |
|---|---|---|
| Goal | Update the attributes of the MOI(s) corresponding to the subject VNF instance (application part) after a VNF has been scaled. | |
| Actors and Roles | 3GPP NM | |
| Telecom resources | 3GPP NM, 3GPP EM | |
| Assumptions | ||
| Pre-conditions | The MOI(s) for the subject VNF instance have not been updated. | |
| Begins when | NM learns that the VNF instance has been scaled, and decides the MOI(s) corresponding to the subject VNF instance (application part) need to be updated. | See use case in clauses 6.4.3.4 in TS 28.525 |
| Step 1 (M) | NM sends a request to EM to update the MOI(s) corresponding to the subject VNF instance (application part). | |
| Step 2 (M) | EM updates the attributes of the MOI(s) corresponding to the subject VNF instance (application part). | |
| Step 3 (M) | EM sends the notifications to NM about the update of the MOI(s). | |
| Ends when (*) | Ends when all steps identified above are completed or when an exception occurs. | |
| Exceptions | One of the steps identified above fails. | |
| Post-conditions | The MOI(s) corresponding to the subject VNF instance (application part) are updated. | |
| Traceability (*) | REQ-NFV_CM_Itf-N-FUN-6, REQ-NFV_CM_Itf-N-FUN-7 |
6.4.5 Update the MOI(s) corresponding to the subject VNF instance (application part) after a VNF instance is scaled (Triggered by EM) p. 16
| Use Case Stage | Evolution/Specification | <<Uses>> Related use |
|---|---|---|
| Goal | Update the attributes of the MOI(s) corresponding to the subject VNF instance (application part) after a VNF instance is scaled. | |
| Actors and Roles | 3GPP NM | |
| Telecom resources | 3GPP NM, 3GPP EM, VNFM | |
| Assumptions | ||
| Pre-conditions | The MOI(s) for the subject VNF instance have not been updated. | |
| Begins when | EM receives the message indicating the VNF has been scaled from VNFM and decides the MOI(s) corresponding to the subject VNF instance (application part) need to be updated. | |
| Step 1 (M) | EM updates the attributes of the MOI(s) corresponding to the subject VNF instance (application part). | |
| Step 2 (M) | EM sends the notifications to NM about the update of the MOI(s). | |
| Ends when (*) | Ends when all steps identified above are completed or when an exception occurs. | |
| Exceptions | One of the steps identified above fails. | |
| Post-conditions | The MOI(s) corresponding to the subject VNF instance (application part) are updated. | |
| Traceability (*) | REQ-NFV_CM_Itf-N-FUN-7 |
6.4.6 Void
6.4.7 Void
6.4.8 Void
6.4.9 Enable/disable the auto-scaling of the VNF instance(s) corresponding to an NE p. 16
| Use Case Stage | Evolution/Specification | <<Uses>> Related use |
|---|---|---|
| Goal | Enable/Disable the auto-scaling of the VNF instance(s) corresponding to an NE. | |
| Actors and Roles | IRPManager | |
| Telecom resources | IRPAgent, VNFM | |
| Assumptions | ||
| Pre-conditions | ||
| Begins when | The operator decides to enable/disable the auto-scaling of the VNF instance(s) corresponding to an NE. | |
| Step 1 (M) | IRPManager requests IRPAgent to change the value of the auto-scaling attribute on VNF instance(s) corresponding to an NE. | |
| Step 2 (M) | EM requests VNFM to enable/disable the auto-scaling of the subject VNF instance(s). | Use case defined in clause 6.4.1.6 of [8]. |
| Step 3 (M) | IPRAgent notifies IPRManager of the completion result of enabling/disabling the auto-scaling of the VNF instance(s) corresponding to an NE. | |
| Ends when | Ends when all steps identified above are completed or when an exception occurs. | |
| Exceptions | One of the steps identified above fails. | |
| Post-conditions | The auto-scaling of the VNF instance(s) corresponding to an NE is enabled/disabled. | |
| Traceability | REQ-NFV_CM_Itf-N-FUN-9 |
6.4.10 VNF instance information synchronization p. 17
| Use Case Stage | Evolution/Specification | <<Uses>> Related use |
|---|---|---|
| Goal | Synchronize the VNF related information in a ManagedFunction instance with the corresponding VNF information in MANO side. | |
| Actors and Roles | IRPAgent | |
| Telecom resources | IRPManager, VNFM | |
| Assumptions | ||
| Pre-conditions | EM has subscribed the VnfLifecycleChangeNotification and VnfInfoAttributeValueChangeNotification (see clause 7.3.3 of [5]). | |
| Begins when | EM receives VnfLifecycleChangeNotification or VnfInfoAttributeValueChangeNotification (see clause 7.3.3 of [5]) from VNFM. | |
| Step 1 (O) | EM performs QueryVNF operation (see clause 7.2.9 of [5]) and obtains the current information of the corresponding VnfInfo object. | |
| Step 2 (O) | If the attribute values on EM do not match those of the current VnfInfo, EM updates these values. | |
| Step 3 (O) | If the attribute values of MOI(s) exposed to IRPManager are changed, IPRAgent notifies IPRManager about the attribute value changes. | |
| Ends when | Ends when all steps identified above are completed or when an exception occurs. | |
| Exceptions | One of the steps identified above fails. | |
| Post-conditions | The VNF related information in the ManagedFunction instance is synchronized with the corresponding VNF information in MANO side. | |
| Traceability |
$ Change history p. 18
