Date
Attendees
Apology
Agenda
- Admin (none)
- Streaming document oimt2022.ND.007_TR-512.8_OnfCoreIm-Control.docx 2nd walkthrough (“review”)
- Note that a new version of the document will be uploaded just before the meeting
- TR-512.5 issues (Qilei Wang)
- prototype is <<Obsolete>>… where is the essential property now covered?
- AOB
Discussion items
Time | Item | Who | Notes |
|---|---|---|---|
|
| ||
| Streaming document | Nigel | Nigel provided a quick overview of the changes.
Further cleaning of the end of the document required. Nigel worked through detail explaining each section.
The primary focus is on the area in the red rectangle with significant coverage of the area in the green rectangle. The description relates to a solution low down in the hierarchy (to simplify the explanation). It is not covering slicing as that happens higher up. Nigel noted that there will need to be some harmonization with the slicing work. The view mapping here is to clean up the model and presentation of all of the information to pass to the orchestrator. Malcolm and Nigel agreed that the VMF is being used for different purposes in the two cases. Nigel explained that the description related to a place in the solution where the are few permanently connected clients that expect live updates so as to maintain an ongoing view that is used to take control actions. Hence Streaming is vital. <broke at this point to go to the TR-512.5 issue> There is a general explanation of streaming in the "autonomous provision of information". Summary of streaming characteristics still needs to be updated. Nigel noted that he had added diagrams that explained the use of the earlier work on signals
The diagrams above highlight the signal and the get. This is followed by the stream model. The diagrams now have a UML component to identify the client and provider as appropriate e.g., as below...
The document now includes data types as well as the classes. Attributes have been added. Comments have been added to the properties. The attributes have been added.
Nigel highlighted the provider stream classes.
Some classes are not fully populated with properties, we may wish to include properties in some of the new classes that do not have TAPI originated detail. Nigel noted that conveyedInformation had no detail and needed to be investigated.
Nigel noted that he had tried to make some of the streams clearer. Brief discussion on get approach considering the request construction and handling of the response which may go to the CC or straight into the view depending upon the specific get. Nigel noted that the complete model is in Figure 6-8. Whist this is dense, it seems sensible to provide a view of the assembly of what has been discussed in earlier session. Nigel then explained the following diagram
Note that the colour or the SD symbol will remain yellow as that essentially depicts data storage. Nigel explained that the diagram to the right of the figure is a summary of a fragment of the controller hierarchy and the main diagram in the middle is a fragment of the fragment. The text in the document explains the flow and this was summarized. Nigel explained the overall pattern and noted that flow may be between CDP and VMF or between CPs (all external flows are between CPs). Some occurrences of the pattern do not have CP etc. Information comes from the devices, gets stored in a nodal view, gets transformed into a network view and stored and then further transformed into an external view and stored before streaming etc. The transformation could be from a proprietary model to TAPI between the controllers or to core etc. Nigel pointed out that the text explains where the document is intentionally not describing some process of activity. The sections 6.6.n will be converted into a numbered list.
The assumption in the sections is that the provider is set up first then the client queries and then connects. Clearly, the provider may add streams etc. as it progresses. Nigel requested that Malcolm should review the next version of this document (once the sections converted to numbered lists etc.).
Malcolm emphasized that the document should not go into detail of specific mappings. Nigel agreed that that was not the intention. Malcolm also emphasized that the scope of the information should not be defined. Nigel agreed. Nigel noted that a .A. document could be used to explain the mappings. Malcolm agreed that a .A. document should cover mapping and slicing examples (just a few). This does not depend in any way on streaming. Nigel agreed. Nigel noted that we could use Core to TAPI as an example. An LTP maps to both a NEP and a CEP. A few examples could lead to a sufficient understanding of mapping. Nigel noted that the streaming section essentially ties together all of the previous described bits of the document to explain how they assemble into a streaming solution. | |
There is no other place in the model where it is represented. Qilei emphasized that this needed. Nigel noted that the property is marked in red on the diagram for no obvious reason.
The type is also <<Obsolete>>. The comment mentions "ProtectionGroup" which is clearly out of date. Chris noted that there was an agreement to move preliminary on to mature after two releases. Nigel agree that this should be done.
Nigel suggested that a global replace on the .uml could be used to do the correction. Note that some properties may not move as they have been changed less than two releases ago. May need to do a diff against the previous release. Could use gendoc to extract a flat form of the model with just attribute names and stereotypes then do a compare. | |||
| 0 min | Next calls | Individual's vacation plan: MB (August 11-31; Sept 19-30), AM (August 15-19), KL (August 22-26; Sept 19-Oct 12)
Future calls agenda items for consideration
|
Overview
Content Tools
Activity