...
OOF impacts are described in OOF_impacts_v1.0.pptx.
ASSUMPTIONS
New Candidate schema to represent NSSI (RAN,Core,Transport)
JSON Viewer | ||||
---|---|---|---|---|
| ||||
{
"candidate_id": "1ac71fb8-ad43-4e16-9459-c3f372b8236d",
"candidate_type": "nssi",
"inventory_type": "nssi",
"inventory_provider": "aai",
"domain": "cn",
"latency": "5",
"max-number-of-UEs": 0,
"coverage-area-TA-list": "[{\"province\":\"??\",\"city\":\"???\",\"county\":\"???\",\"street\":\"?????\"}]",
"ue-mobility-level": "stationary",
"resource-sharing-level": "0",
"exp-data-rate-UL": 100,
"exp-data-rate-DL": 100,
"area-traffic-cap-UL": 100,
"area-traffic-cap-DL": 100,
"activity-factor": 0,
"e2e-latency": 0,
"jitter": 0,
"survival-time": 0,
"exp-data-rate": 0,
"payload-size": 0,
"traffic-density": 0,
"conn-density": 0,
"reliability": "99.999",
"service-area-dimension": "",
"cs-availability":""
} |
SO - OOF INTERACTION
JSON Viewer | ||||
---|---|---|---|---|
| ||||
{
"serviceProfile":{
"latency": 2,
"security": "High",
"reliability": 99.9999,
"trafficDensity": 1,
"connDensity": 100000,
"expDataRate": 50,
"jitter": 1,
"survivalTime": 0
},
"requestInfo":{
"transactionId":"d290f1ee-6c54-4b01-90e6-d701748f0851",
"requestId":"d290f1ee-6c54-4b01-90e6-d701748f0851",
"callbackUrl": "http://0.0.0.0:9000/osdfCallback/",
"sourceId": "SO",
"timeout":5
},
"NSTInfo":[
{
"modelInvariantId":"fda3c1e8-7653-4acd-80ef-f5755c1d3859",
"modelVersionId":"a6906768-1cae-4e78-acd1-d753ac61f3e8"
}
]
} |
[unit : (latency - ms) ; (expDataRate - Mbps) ; (survivalTime - ms) ; (jitter - micro sec) ; (connDensity - /km2) ; (trafficDensity - Tbps/km2)]
ATTRIBUTE POLICY:
JSON Viewer | ||||
---|---|---|---|---|
| ||||
{
"service":"attributePolicy",
"policyName":"OSDF_FRANKFURT.AttributePolicy_vNS_1",
"description":"Attribute Policy for Network Slicing (NS)",
"templateVersion":"OpenSource.version.1",
"version":"OpenSource.version.1",
"priority":"1",
"riskType":"test",
"riskLevel":"3",
"guard":"False",
"content":{
"identity":"urllc_attribute",
"policyScope":[
"URLLC"
],
"policyType":"attribute",
"resources":[
"URLLC"
],
"attributeProperties":{
"serviceProfile":{
"latency":{
"lte":"10 ms"
},
"reliability":{
"gte":"99.999"
}
}
}
}
} |
VNF POLICY:
JSON Viewer | ||||
---|---|---|---|---|
| ||||
{
"service":"vnfPolicy",
"policyName":"OSDF_FRANKFURT.vnfPolicy_URLLC",
"description":"vnfPolicy",
"templateVersion":"OpenSource.version.1",
"version":"test1",
"priority":"6",
"riskType":"test",
"riskLevel":"3",
"guard":"False",
"content":{
"identity":"urllc_prop",
"policyScope":[
"URLLC"
],
"policyType":"vnfPolicy",
"resources":[
"URLLC"
],
"applicableResources":"any",
"vnfProperties":[
{
"inventoryProvider":"aai",
"inventoryType":"service",
"customerId":"5G-customer",
"orchestrationStatus":"ACTIVE",
"equipmentRole":""
}
]
}
} |
OPTIMIZATION POLICY
...
width | 600 |
---|---|
height | 700 |
Table of Contents |
---|
Assumptions
- The capability set in the template will not contain range of values
- Subnet template details will be loaded as Subscriber policy
- NSI Name will be unique in AAI
- Slice profile in NSSI is chosen based on latency (Conductor)
OSDF - HAS:
...
width | 600 |
---|---|
height | 700 |
...
Illustrations
1. Call from SO to OOF to Get suitable NST
...
2. Call from SO to OOF to get suitable NSI
...
Inputs: Service Profile parameters, NST id
...
Assume the latency ranges supported by the above NSSTs which are part of NST_URLLC1 are as follows (fetched from Attribute Policy).
NSST id | Latency range supported |
---|---|
NSST_URLLC_RAN2 | (5..30) |
NSST_URLLC_Core1 | (10..100) |
NSST_URLLC_TRAN2 | (7..30) |
Now there are 4 possible solution categories that OOF can provide in the response to SO.
...
To address all cases above, HAS is invoked with 3 demands (NSST-RAN, NSST-Core, NSST-Transport).
Solution 1
----------
NSI-10 which has URLLC1_NST
NSI-null with NSSI-R-1, (Core-slice profile), NSSI-T-1
Let us assume that the NSI inventory is as follows:
NSI Id | NST Id | NSSI RAN Id | NSSI Core Id | NSSI Transport Id |
---|---|---|---|---|
NSI-1 | NST_URLLC1 | NSSI-R-1 | NSSI-C-2 | NSSI-T-1 |
NSI-2 | NST_URLLC2 | NSSI-R-6 | NSSI-C-4 | NSSI-T-3 |
NSI-3 | NST_eMBB2 | ... | ... | ... |
NSI-4 | NST_URLLC2 | NSSI-R-1 | NSSI-C-1 | NSSI-T-1 |
... | ... | ... | ... | ... |
NSI-10 | NST_URLLC3 | NSSI-R-5 | NSSI-C2 | NSSI-T-4 |
Say, HAS returns the foll. solutions:
Solution 1 = (Solution 2
----------
NSSI-R-1, NSSI-C-newC2, NSSI-T-2 (HAS to OSDF) => New NSI (OOF to SO) with slice profile
T1)
Solution 2 = (NSSI-R-1, NSSI-C2(Core-slice profile), NSSI-T-1 (HAS to OSDF) => Re-use NSI-1 (OOF to SO)3) (assuming NSSI-T-3 has NSST_URLLC_TRAN2 as its template).
OSDF then does the following:
- For Solution 1, it sees:
NSSI-R1 is part of NSI-1,NSI-4
NSSI-C2 is part of NSI-1, NSI-10
NSSI-T1 is part of NSI-4, NSI-1
There is a common "NSI" which is "NSI-
...
1". So NSI-1 can be reused. It fills the shared NSI solutions part of response to SO with NSI-1.
- For solution 2, NSSI-R-1, NSSI-C-new, NSSI-T-3 => It fills New NSI solutions part of the response to SO with NSSI ids and slice profile(s).