Closed dsilhavy closed 5 months ago
Looks like a good idea to have the readme covering what is essentially related to building, installing etc of this particular repo. And then refer to other repos when it comes to e.g. managing directly AF, etc.
If I understand the rationale, this Application Provider repo could integrate at some point some UE data collection from the rt-5gc-data-collection-application-function which may be integrated as part of the web server. However the actual testing/interfaces/commands related to that will be part of the readme or wiki in that concrete repo.
@jordijoangimenez @stojkovicv @rjb1000 I restructured the documentation. The Readme file in the root folder now links to Readme files in the corresponding subprojects. I think it is cleaner that way, and we don't overload the root Readme with too much information.
Nice idea to restructure it in this way, @dsilhavy.
Looks like a good idea to have the readme covering what is essentially related to building, installing etc of this particular repo. And then refer to other repos when it comes to e.g. managing directly AF, etc.
If I understand the rationale, this Application Provider repo could integrate at some point some UE data collection from the rt-5gc-data-collection-application-function which may be integrated as part of the web server. However the actual testing/interfaces/commands related to that will be part of the readme or wiki in that concrete repo.
I think we should discuss documentation questions in the call on Friday. We need to identify clear rules where to put which parts/aspects of the documentation:
As an example, in the Readme files of this repo we are referring to https://github.com/5G-MAG/rt-5gms-application-function/wiki. However, testing M1 is related to the tools we offer in this repo. We could also move all of this to https://5g-mag.github.io/Getting-Started/ and only keep the installation instructions in the Readme files of each repository.
I think we should discuss documentation questions in the call on Friday. We need to identify clear rules where to put which parts/aspects of the documentation:
- What goes on https://5g-mag.github.io/Getting-Started/
- What goes directly to the repositories (Readme in the root folder)
- What goes into the Wiki of a repository
As an example, in the Readme files of this repo we are referring to https://github.com/5G-MAG/rt-5gms-application-function/wiki. However, testing M1 is related to the tools we offer in this repo. We could also move all of this to https://5g-mag.github.io/Getting-Started/ and only keep the installation instructions in the Readme files of each repository.
Please add to the agenda. I'm also preparing up-to-date supporting slides that will be uploaded today.
If I understand the rationale, this Application Provider repo could integrate at some point some UE data collection from the rt-5gc-data-collection-application-function which may be integrated as part of the web server.
Not sure about this yet. A reference implementation of the external event consumer entity (called Event Consumer AF in the EVEX reference model) could live in another repository altogether (e.g. rt-evex-event-consumer-af) since the generic EVEX architecture is not specific to 5G Media Streaming.
However, a reference implementation of an Event Consumer AF that knows about the five event types relating to 5G Media Streaming could potentially live in this rt-5gms-application-provider repository, I think. TS 26.501 figure 4.7.1-1 certainly depicts the Event Consumer AF as part of the 5GMS Application Provider in the specific instantiation of the generic EVEX architecture for 5GMS. This could range from the simple (just dump received events to disk) to the fancy. For example, a student project might look at correlating the five different event types and infer useful performance statistics from them using a data analytics engine.
@jordijoangimenez Let's please synchronise yours https://github.com/5G-MAG/rt-5gms-application-provider/pull/32 with this PR, so that all documentation modification can be done at once. @dsilhavy opened feature/documentationUpdates
branch, all changes can be pushed directly to it.
Perfect, let me proceed
I've rebased these changes onto the latest HEAD
@dsilhavy, please merge this one and I'll make changes on top as suggested by @stojkovicv. I won't have time until Wed/Thu.
@jordijoangimenez @stojkovicv @rjb1000 I restructured the documentation. The Readme file in the root folder now links to Readme files in the corresponding subprojects. I think it is cleaner that way, and we don't overload the root Readme with too much information.