B.1 Intent Life Cycle Management
28.3123GPPIntent driven management services for mobile networksManagement and orchestrationRelease 17TS
As the MnS producer’s (i.e. 3gpp system) capabilities (e.g. number and/or availability of the system resources) can change even after the Intent is accepted by the MnS producer, the Intent content (i.e. a list of Intent Expectations) might not be best aligned with the MnS producer’ capabilities. For example, the resources in MnS producer are overbooked, and the intent content is failing to meet expectations of the MnS consumer or the resources of the MnS producer become underbooked which makes such a solution very expensive and therefore useless. Hence the creation/adjustment of an Intent content (i.e. a list of Intent Expectations) and keeping it aligned with the MnS producer’s capabilities, can be automated.
This means that the life cycle of the Intent can begin before Intent content is retrieved by the MnS producer, e.g. the Intent content is being defined in a MnS consumer based on requirements towards a MnS producer (e.g. to deliver a service with certain characteristics), then be optimized based on the MnS producer’s capabilities (e.g. availability of MnS Producer resources in certain area, time, etc.), then be refined if the initially captured requirement needs further detalization, etc.
The intent lifecycle consists of the following phases.
Figure B.1-1: Intent Lifecycle Phases
Detection:
In the detection phase, the MnS Consumer as the system generating the intent content (a list of expectations), identifies if there is a need to define new or change/remove existing intent expectations to set requirements, goals, and constraints. The MnS Consumer has its own terminal expectations to fulfill. It would break its terminal expectations down into a suitable set of detailed instrumental expectations. Typically, these instrumental expectations need to be fulfilled by other management functions and domains and therefore they need to be not only defined but distributed to suitable MnS producer. In the detection phase, the MnS consumer can react to changes in its own terminal expectations or to changes in the fulfillment in its instrumental expectations. In this respect the MnS consumer deriving the expectations will need to collect information about the expectation’ fulfillment. Intent reports coming from MnS producer, as a system to receive intent expectations are one source for this information. Through intent reports the MnS Consumer is able to react on intent handling outcomes in the MnS producer. In any case it is task of the MnS consumer to assure the fulfillment of its terminal expectations and the first step is to detect if any changes are needed in its instrumental expectations.
Investigation:
In the investigation phase, the MnS Consumer finds out what intent content (a list of expectations) are feasible. This has two aspects: first, it needs to find right MnS producer that have the right domain responsibilities and support the intent expectations the MnS consumer wants to define. MnS producer capability management and detection would be used for this process.
The other aspect of investigation would be finding out if the wanted intent expectations are realistic. This means, if the MnS producer would be able to successfully reach the wanted expectations. This depends on the current resource situation and capabilities of the system and can vary over time. Typically, the feasibility of intent expectations is done through a guided negotiation process between the MnS Producer and MnS Consumer. The MnS Consumer can explore what the handling result of wanted intent expectations would be, what would be the best result the MnS producer can achieve, or what would be the most challenging requirements, the aspiring MnS producer can offer to fulfill.
Definition:
At the end of the investigation phase the MnS consumer knows what is possible and what the MnS producer to be involved. By combining this information with the needs that were identified in detection, the MnS Consumer can now decide and plan all needed intent expectations. In the definition phase the MnS consumer formulates the intent expectations it needs to use.
Distribution:
In the distribution phase the MnS Consumer contacts a MnS producer in order to create a new intent object or modify or change an existing one to include the intent expectations derived in the Definition phase. This way the MnS consumer acts on the plan it has made in definition phase. In this phase a MnS producer starts handling the intent expectations by receiving them and included in the intent object. The MnS producer decides if it can accept the intent expectations. If not, it would send a report with the rejection reason back to the MnS consumer. While this finishes the lifecycle of this particular intent, the MnS consumer can start over with detection to create a new plan. If the MnS producer accepts the intent, it starts operating based on it.
Operation:
Each intent expectations yet another set of requirements, goals and constraints to be considered for decisions and actions by the MnS producers. The MnS producers operate their domains of responsibility according to the given intent expectations. They also report back to the MnS consumer about status and success while continuously reacting to intent fulfillment threats. Intent reports would be evaluated by the MnS consumer as part of its detection process, which leads to the next iteration of the intent life cycle.
Annex C (informative):
Mapping the 3GPP and the TM Forum intentExpectation Models
The TM forum defines the structure of an intent as a list of expectations with each expectation containing the requirements goals and constraints to be achieved. The expectation is defined to contain 3 attributes – the icm:target, icm:propertyParams and the icm:deliveryParams.
The IntentExpectation defined in 3GPP (see clause 6.2.1.3.1) contains some attributes which can be mapped to the TM Forum model.
Table C.1 illustrates the mapping between 3GPP Intent Expectation and TM Forum ICM IntentExpectation.
Table C.1. Mapping between 3GPP Intent Expectation and TM Forum ICM IntentExpectation
|
3GPP Intent Expectation |
TM Forum Intent Expectation (IG1253A v1.1.0 [7]) |
|
Attribute |
Attribute |
|
expectationObject.ObjectInstance |
icm:target |
|
expectationTargets |
icm:propertyParams |
|
expectationContexts |
|
|
expectationObject.objectType |
icm:deliveryParams |
|
expectationObject.ObjectContexts |
Annex D (informative):
Change history
|
Change history |
|||||||
|---|---|---|---|---|---|---|---|
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2022-06 |
SA#96 |
SP-220491 |
Presented for approval |
2.0.0 |
|||
|
2022-06 |
SA#96 |
Upgrade to change control version |
17.0.0 |
||||
|
2022-06 |
SA#96 |
Editorial fixes according to EditHelp |
17.0.1 |
||||
|
2022-09 |
SA#97e |
SP-220852 |
0001 |
– |
F |
Add missing guidelines for using scenario specific intent expectation for intent driven use cases |
17.1.0 |
|
2022-09 |
SA#97e |
SP-220852 |
0002 |
– |
F |
Correct the misalignment information in Annex C |
17.1.0 |
|
2022-09 |
SA#97e |
SP-220852 |
0003 |
– |
F |
Update intentNRM yaml file to distinguish the generic intent expectation part and scenario specific intent part |
17.1.0 |
|
2022-09 |
SA#97e |
SP-220852 |
0004 |
– |
F |
Correct procedures for intent management |
17.1.0 |
|
2022-09 |
SA#97e |
Alignment with content in FORGE |
17.1.1 |
||||
|
2022-12 |
SA#98e |
SP-221175 |
0005 |
2 |
F |
Correction to Context and Expectation Object definitions |
17.2.0 |
|
2022-12 |
SA#98e |
SP-221175 |
0006 |
2 |
F |
Correction to Stage 3 and Stage 2 definitions for Intent Driven Management |
17.2.0 |
|
2022-12 |
SA#98e |
SP-221175 |
0007 |
2 |
F |
Addition of notification clauses, correction of mis-numbered clauses and addition of common notifications |
17.2.0 |
|
2022-12 |
SA#98e |
SP-221175 |
0008 |
– |
F |
Add clarification for ambiguous relation description between classic MnS and intent MnS |
17.2.0 |
|
2022-12 |
SA#98e |
SP-221175 |
0009 |
– |
F |
Update Enum value to use upper case characters to align with TS 32.156 (Stage2 and Stage3) |
17.2.0 |
|
2022-12 |
SA#98e |
SP-221175 |
0010 |
– |
F |
Correct the procedure for create an intent and modify an intent |
17.2.0 |
|
2022-12 |
SA#98e |
SP-221175 |
0011 |
– |
F |
Add missing generic requirements for intent driven MnS |
17.2.0 |
|
2022-12 |
SA#98e |
SP-221175 |
0012 |
1 |
F |
Correct intent class diagram |
17.2.0 |
|
2022-12 |
SA#98e |
SP-221175 |
0013 |
– |
F |
Correct notFulfilledReasons attribute |
17.2.0 |