ONAP Service IM Minutes 20190424

Owned by guochuyi
Last updated: Apr 30, 2019
2 min read

Participants



Agenda 

  1. Enhanced Service Information Model for Nested and Shared Services 

  2. Introduction of 5G Riders on the Storm @James O'Sullivan

Minutes 

  1. Introduction of 5G Riders on the Storm

           Materials presented by @James O'Sullivan are here ODA-150 Towards a more Generic Slice Template GST --5GROTS Catalyst.pdf

  • Brief introduction: This proposal aims at GSMA GST enhancement, the goal is to create concrete API for slice management suitable for discussion with 3gpp and contribute to GSMA network slice template work. The basic idea is slice parameters should distinguish customer facing and resource facing based on TMF SID structure, because some are too technical that don't need to be known by customsers.

  • Given Proposal: Combining flat GST with Structured JSON “schema” to be an enhanced GST with improved Slicing API. GST may need to add Device profile, Traffic profile and etc.

  • What is the service family conception?
    This is used to simplify the current structure into service types and service profiles, some parameters can be grouped as families. It comes from NGMN 5G white paper, families can be mapping to number of categories, user will order the customer they want to consumer to have the category.

  • Templates will be separated into CFS and RFS view and provide corresponding mechanism.

  • What will be bring to ONAP? Target on next week to give a feedback on service information model.

     2.  Enhanced Service Information Model for Nested and Shared Services 

          This time mainly focus on the filter functionality.

  • Thinh thinks there is no need to have a filterId and filterRules for service information model, a composite service should have the information for its nested services, we don't need to know the inside services, but only know the outside presence.

  • Borislav illustrates the usage for filter. Filter realization is mature and implemented by SDC. When looking for services, we can use filter to choose the right satisfied nested services inside. For example, when instantiating service A, we have 5 service instances with different properties(latency, mobility,...), we need to choose one of them to compose A. The requirement is the latency of B should lower than A, the latency information can't be known in design time, only can know while instantiation, this is where the filter works.

  • Next step:

    1. Leave one more week to receive coments.

    2. Go through and make decisions one by one on the proposal attributes.

    3. Borislav will do some updates for the slides on the pages related to Thinh's proposal.

         

Recordings 

audio_only.m4a

zoom_0.mp4