One complicating factor is that M-CORD and XOS use the term "Slice" but each with a different meaning. So let's call these two MSlice and XSlice:
XSlice = Resources allocated to a Service (Set of Instances, Set of Networks)
MSlice = Resources allocated across a set of Services to some class of users (Set of XSlices)
The root M-CORD requirement is the ability to configure a POD with multiple MSlices, but also with multiple personalities.
New feature 1 - two layer services:
Start from CORD 3.0, we plan to have two level services for M-CORD inside XOS.
- The layer 1 services will be:
- vBBU
- vMME
- vSGWC
- vPGWC
- vSGWU
- vPGWU
- vHSS
- vSM (session management)
- vMM (mobility management)
- The layer 2 services will be compose by layer 1 services:
- EPC as a service
- Connectionless EPC as a service [TODO]
- Static device EPC as a service [TODO]
- disaggregated MME based EPC as a service. [TODO]
Note: All the services described above can be used by any use cases or demos. We treat it as platform services. We also can have use case services, such as Public safety as a service, PassiveTest as a service, ActiveTest as a service.
New feature 2 - automation:
In M-CORD 2.0, after we launch a new VM under a service, such BBU, we need manually login the VM, and config the BBU software, such as config the IP address of MME and then run the BBU software. in M-CORD 3.0, we will try to automatic those manual steps.
Refactoring all the existing features from M-CORD 2.0 to M-CORD 3.0:
Since XOS changed a lot from CORD 2.0 to CORD 3.0. So M-CORD team also need to refactor all the M-CORD relative functions.
It mainly includes two parts:
(1) service profiles; (2) M-CORD services.
We already break down the whole work into small tasks. You can see them in M-CORD board:
this board shows the current status in sprint 21 tasks and the Backlog tasks.
in sprint 21 tasks , you can see what we finished, what are in progress, what are going to do.
All the tasks in the "Backlog" section belongs to TODO list.