...
1. PLMN-ID in 3GPP is not used to identify the slice (certainly it is used to identify the PLMN)
3GPP did not develop (yet?) the concept of how two slice instances can relate to two different PLMNs. I personally like this idea, but ...
2. "Existing CN" and "new CN" literally mean that there are two Core Networks. Probably the point is that there are two NSSIs that consist of CN NFs.
(Peter L): Correct - and we don't say that 3GPP does. We propose here to re-use the RAN sharing support for multipple PLMNs as if each such PLMN represent a slice of its own. As many products support this RAN sharing scenario (including transport separation based on PLMN) we obtain a scenario that from a management point of view is expected to be similar to working with slice support as we may find in a 5G CN and RAN.
2. "Existing CN" and "new CN" literally mean that there are two Core Networks. Probably the point is that there are two NSSIs that consist of CN NFs.
(Peter L): Correct.
3. "It is known from ONAP R1 how to instantiate and deploy a minimal viable CN" - probably means that 3. "It is known from ONAP R1 how to instantiate and deploy a minimal viable CN" - probably means that R1 ONAP will have sufficient functionality to support deployment of 3GPP Core Network. If this is the statement, it needs some explanation. For example, probably LCM of VNFs will be supported. The LCM of NSs (in terms of ETSI NFV) - I don't know; will appreciate reference that confirms. Same question about support of signaling transfer, about OAM functionality. Many questions probably cannot be answered simply because R1 is not sufficiently documented.
(Peter L): I agree to that - it is slightly problematic, but if the R2 use cases cannot build on top of already delivered functionality demonstrated as R1 use cases, the we do have a problem. This has to be checked.
4. Use of 4. Use of VLAN tagging on backhaul connections needs at least explanation or reference. VLAN tagging after all is a LAN technique while backhaul typically is WAN.
(Peter L): Yes, we need to rephrase that to include whatever transport network separation technique suitable (any combination of VLAN, VXLAN, VPN or other).
5. Relation between slicing support and RAN sharing is 5. Relation between slicing support and RAN sharing is not defined in 3GPP. There is a reference in 28.801 to RAN sharing as an example of B2B2X type of service, but relation of that to slicing is not defined. of that to slicing is not defined.
(Peter L): As above, that does not stop us from experimenting with the concept of managing the adding of a CN and PLMN to make the RAN becomming shared between two PLMNs? From a management point of view that is the closest we can get to the use case "add a new slice" in an LTE RAN without waiting for comming standards and implementations?
I can continue, but prefer to stop at this point. I think we should follow the concepts clearly defined and agreed in the relevant SDOs. It would be bad idea to deviate from 3GPP / NGMN definitions and/or invent our own definitions.
(Peter L) The point here is not to invent any new definitions at all - the point is to describe a slice related management use case using the RAN, CN and TN technologies we already have, in order to expand the capabilities of ONAP (or show that they are already sufficient). We are not here to develop the CN, TN or RAN, right?
However, as ONAP has a slightly different structure and functional composition than what is described by NGNM or 3GPP, we effectively do work with ONAP specific definitions in some management areas. I can continue, but prefer to stop at this point. I think we should follow the concepts clearly defined and agreed in the relevant SDOs. It would be bad idea to deviate from 3GPP / NGMN definitions and/or invent our own definitions.
Goal for this Use Case:
To show that ONAP can be used to desgn and deploy the Service 2 in a new CN and selected portion of a RAN currently providing Service 1 using NSI A, see Figure 1.
...