search

AMSP-04 / NETN-ETR

NATO Education and Training Network (NETN) Entity Tasking and Reporting (ETR) Module
Other
2 stars 0 forks source link

Role of CommunicationNetworkIds in tasks/reports unclear #33

Closed bergtwvd closed 4 years ago

bergtwvd commented 4 years ago

ETR is about tasking/reporting entities from EXCON point of view. A task is for example to Jam a comms network,

I doubt whether tasks/reports themselves should be subjected to this. And what the relationship is with JamCommunication and NETN-COM.

One option is to drop the CommunicationNetworkIds from ETR_Task and ETR_Report.

lofstrandbjorn commented 4 years ago

I doubt whether tasks/reports themselves should be subjected to this. (I AGREE!) ETR is about the interface between an "operator" and CGF. Modelling and Simulation of the transmission of messages is a different thing.

JamCommunication should be a task to a CGF to do some Jamming on identified Communication (i.e. influencing a NETN-COM Communication object status). The task should be picked up by the federate/s directly or indirectly modelling the Communication object state.

lofstrandbjorn commented 4 years ago

Create a feature branch, make proposed changes and create pull-request for review.

bergtwvd commented 4 years ago

I don't think I need a branch for the proposal. We need to decide whether to remove the parameter CommunicationNetworkIds from ETR_Task and ETR_Report, or not. The proposal is: yes.

We have not thought through this topic well enough. Jamming etc should be seen in relation to NETN-COM and the modelling of Radio messages in the RPR.

A task JamCommunication (or JamRadio, see https://github.com/AMSP-04/NETN-ETR/issues/34) is fine to have in the ETR set.

ChristianPick commented 4 years ago

If you remove the CommunicationNetworkId from ETR_Task and ETR_Report there is no indication left how the messsage was transported. Therefore there would be no way to decide whether the messages should be received or not. Without this ID a second interaction like "TransmitMessage" would be neccessary including thie CommunicationNetworkId and the ID of the message. A receiver would have to wait for this interaction for each task/report to decide how to proceed. Sounds very complicated. Please keep the CommunicationNetworkId!

I see two different use cases for the tasks: 1) A user commands god-like some CGFs. In this case the Id should be left blank (the NETN-COM has no effect) 2) Communication between entities or the user as a commander as part of the scenario. In this case the Id should be filled to indicate the way of transport.

bergtwvd commented 4 years ago

In my view the ETR is for EXCON users and the Communication Network is more related to eg Radio messages (derived from the RPR class). We have not really thought this topic through well enough.

Also, at the moment all ETR parameters are required, thus also the CommunicationNetworkId.

ChristianPick commented 4 years ago

Is there a reason why you want to limit the use of NETN-ETR to EXCON users? I see no indication in the definition / description of it to do so. Why should this not be used within or between simulations or C2 systems? As far as I remember one purpose of BML (LBML/HBML) was to increase the interoperability of systems, not only to define a standard way humans can interact with a system.

bergtwvd commented 4 years ago

I think we have not closed this discussion yet and come to a conclusion. There are arguments for either approach.

If we keep the network info in, then the classes where this parameter gets added need to be reviewed. Currently the CommunicationNetworkIds is only specified in ETR_Task and ETR_Report. This is not complete.

From C2 point of view a commander may also want to cancel all tasks, and receive task status reports from subordinates. So, the CommunicationNetworkIds also needs to be in ETR_TaskManagement.

However, do the QueryCapabilitiesSupported classes under ETR_TaskManagement make sense in C2? These classes were initially defined under ETR_SimCon and in my view they should be moved back. Definitely if CommunicationNetworkIds gets added in ETR_TaskManagement.

And finally, ETR_SimCon will not have a CommunicationNetworkIds parameter. These are truly EXCON tasks.

lofstrandbjorn commented 4 years ago

Proposal. Add CommunicationNetworkIds to TaskManagement and move QueryCapabilities and CapabilityiesSypported to SimCon. Change datatype of CommunicatioNetwokIds to array of Text64.

lofstrandbjorn commented 4 years ago

I put Text64 and ArrayOfText64 datatypes in NETN-BASE => Text64 removed from NETN-COM.

bergtwvd commented 4 years ago

Done