Multi talkers - Qbv network

[renemarcker]

Hi, I am a student working on some TSN, where I am using your framework to simulate Qbv.

I work from the example in the core4inet, the IEEE8021Qbv. I understand most of the configuration in the ini files, but some questions:

1. in the node1, there is defined a talker :
   ----- Talker with Q Traffic ---------
   **.node1.app[0].typename = "IEEE8021QTrafficSourceApp"
   **.node1.app[0].destAddress = "0A-00-00-00-00-03"
   **.node1.app[0].payload = intWithUnit(uniform(1500Byte, 1500Byte))
   **.node1.app[0].sendInterval = 500us
   **.node1.app[0].priority = 7
   **.node1.app[0].vid = 1
   **.node1.phy[*].taggedVIDs = "1"

and in node 2, the only sink is defined as :
**.node2.app[1].typename = "BGTrafficSinkApp"
**.node2.app[1].srcAddress = "0A-00-00-00-00-01"

but this sink is to BGTraffic? how do you defined talker and listener according to applications?

I have tried to have two talker in node 1 with Q traffic and two of those sink, only the first talker sent data and only the first sink received.

2. I would like to have seven TSN flow and one BE between two nodes, but it seems not to go further then to the switch. not possible to have more talkers of the same type traffic in one node?

3. I have an idea some of these line have something to to with it, but I have no idea their impact:

• node1.app[0].vid = 1
• node1.phy[*].taggedVIDs = "1"
• **.switch1.phy[0].untaggedVID = 0
• **.switch1.phy[0].taggedVIDs = "1"
• **.switch1.phy[1].untaggedVID = 1
• **.switch1.phy[1].taggedVIDs = "0,1,2"
• **.switch1.phy[2].untaggedVID = 1
• **.switch1.phy[2].taggedVIDs = "0,1,2"
  What do this lines implact?

Hope I described my situation in depth and I will look forward for your responds :)

best regards

[THaeckel]

Hi,
thanks for your interest in our simulation models. I hope I can answer your questions:

1. Why ist the Sink App BGTraffic?
   BGTraffic sinks can receive all Ethernet frames that are 802.1Q traffic or BGTraffic. There is another module called "IEEE8021QTrafficSinkApp" which you can use instead of BGTrafficSink.
2. Having multiple Talkers:
   It is possible to have multiple talkers of the same type. I've just tried adding another "IEEE8021QTrafficSourceApp" in node 1 in the IEEE8021Qbv example and it is working as expected.
3. Regarding the impact of (un-)tagged VIDs
   VIDs are the VLAN id's allowed at the physical port. taggedVIDs sets the allowed VLAN ID's for 802.1Q frames at the port, while untaggedVID sets which VLAN id should be used for frames without a VLAN tag.

For more insight, I would need your complete network. From here I can only suggest checking whether you use the correct VLAN ids for the source apps. As you use the IEEE8021Qbv example another problem might be that the gate of the priority you are using for the 802.1Q frame is never open. So I would suggest checking your gate control list settings and the priorities of your TSN streams.

I hope this helps.
Best
Timo

[renemarcker]

ownSetup.zip

Hi Timo,
thank you for your answer. Good to hear it is possible and there is the IEEE sink. I have attach my network, so if you can see on the VIDs and the general config, so you maybe able to tell me my errors.

[THaeckel]

I've looked at your ini files and there are some configuration errors. The real problem lies in the GateControlList Configured at the switch.
note: I have deleted node 3 and 4 as they are not in use.
node1:
Your Q traffic sink won't receive anything because there is no node 4.
Your other apps work as expected and are sending frames.
node2:
In your configuration only app[0] will receive frames as the configuration at the end does not override.
**.node2.bgIn.destination_gates = "app[0].in" shold be removed.
**.node2.bgIn.destination_gates = "app[0].in, app[1].in" is needed for both apps to receive frames.
The apps will filter the frames with the correct mac addresses they are listening to.
switch1:
**.switch1.phy[].shaper.gateControlList.controlList = "o,o,o,o,o,C,C,o:0;o,o,C,C,C,C,C,o:0.002;C,C,C,C,C,o,o,o:0.003;o,C,C,C,C,C,C,o:0.004"
You use an IEEE8021QbvEtherSwitch which has a IEEE 802.1Qbv GateControlList module (you can navigate in the simulation by double clicking the switch -> phy[1] -> shaper where you will find transmission gates. Some of them are closed which means frames of this priority are not transmitted.
Your configuration will open these gates for a short amount of time every period but the credit based shaper will not allow more than one frame in the whole simulation as there is no stream reserved.
**.switch1.phy[].shaper.transmissionSelectionAlgorithm[6].typename = "CreditBasedShaper"
**.switch1.phy[*].shaper.transmissionSelectionAlgorithm[6].srClass = "B"
To have a sending + receiving app that will reserve a certain bandwidth at the shaper, please look at the AVB examples. If you remove the shaper configuration and look inside the switches output shaper you will see packets building up in the queues and beeing processed after the list changes.

Please check the 802.1Qbv standard to see how the GateControlList works. Stream reservation is currently only supported with AVB talker and listener apps, as our 802.1Q apps dont use bandwidth reservation.