I would like to simulate voip in a wimax network. What I would like to measure are the QoS parameters such as IPTD, IPDV and IPLR. I am new to the ns-3 simulator and I can't find anything about QoS measurment. I've already searched in google and it seems that there is nothing like QoS library? If I am correct, how to measure these parameters in this simulation tool? If not, could please someone give me some advice where I can find such library?
From my short experience,
Generally you need to use the flowMonitor helper class to get the statistics.
Refer below.
http://www.nsnam.org/doxygen/classns3_1_1_flow_monitor_helper.html
If it is just the basic statistics like bytes received, sent etc, you have already functions in the packet class that can be used to get the values. Else you need to define them and write methods to do the calculations.
I am not an expert in wireless world, but you can find an example here
http://personal.ee.surrey.ac.uk/Personal/K.Katsaros/media/ns3lab-sol/lab-5-solved.cc
Related
I want to write to the holding registers an actuator of mine has, but I've only recently started using pymodbus and I'm a little uncertain about some of its commands. As far as I've understand the primary write command looks like this:
write_register(address, value, **kwargs)
But I'm uncertain about how I "define" which kind of register I write too. Unlike other modbus libraries I've used, in pymodbus I can't define which kind of register I write too. As far as I understand of modbus there's coils, input registers and holding registers. I've read that you can't write to input registers, but how can I be certain I write to holding registers? If I write 1 in address in the write_register will that always be a holding register with that address?
Thank you in advance.
You need to know a little bit more about your actuator. Do you have a datasheet about it? If yes, you need to find a map registers where all the addresses are given for registers where the actuator's information are stored. Here an example where you can find this kind of registers map : SIMEAS Pxxx Com-Modbus Datasheet.
Be careful, sometimes you need to add or subtrace 1 to your register address because the guys who implement this did in this way. Read your datasheet carefully.
So if you need to write something in a particular register, you need the correct address of the register, the value you want to write in the correct format, and the client of the library ModbusClient.
You should have something like this :
client = ModbusClient(host='YOUR_IP_ADRESS', port=xxx)
client.connect()
client.write_register(REGISTER_ADRESS, PAYLOAD, UNIT)
Hope this will help a little. You can also go further by reading the Pymodbus documentation.
I'm new to SUMO, Veins, OMNET++ and simulations with a bit background of networks. I have successfully setup environment and run veins 4.6 demo application. On google found that unlike RSU, Car modules are added on the fly.
In demo example car nodes send Airframe11p message, i'm not getting where this message is being populated because in TraCIDemo11p.cc methods (onWSA, onWSM, handleSelfMsg, handlePositionUpdate) we are dealing with WSM message types and BaseWaveApplLayer::checkAndTrackPacket methods ensures that message being sent is either BSM, WSM or WSA.
In veins\src\veins\modules\messages AirFrame11p.msg file exists but on finding references of "AirFrame11p" in project, matches are found in AirFrame11p_m.h and AirFrame11p_m.cc only. If demo is not using these files then for what purpose these files are added? and from where simulation gets the annotation of AirFrame11p.
I'm trying to simulate a car accident scenario without RSU using V2V communication, have replaced demo map with mine, generated random routes, now trying to remove RSU from demo application and exploring to send customized messages (including geo location, speed, direction, time etc) to nearby vehicles in specified range e.g. 100 meters using WiFi direct.
If i'm confusing something then please guide me. Thanks.
The short answer: The AirFrame11p message is a lower level message that encapsulates the upper layer messages. Just use the application message type that is appropriate for your application. If you want to replace the physical layer with WiFi direct instead of 11p, and you're starting from scratch, you're probably in for quite a bit of work, since the VEINS PHY implementation is very intricate. If you have an existing implementation of WiFi direct, it may be worth investigating the integration of VEINS' TraCI implementation with that code.
Encapsulation in VEINS
You are correct that the message types at the application layer are more diverse -- these message types (BSM and WSM) are used to encapsulate "application" behavior; it's just not very well visualized in the simulation execution. You can pause the simulation and look (for example) under scheduled events, where the queued packets can be examined visually.
Unlike regular networks, where such messages would be packaged in IP, MAC and PHY encapsulations, VEINS uses the following encapsulation process: BSMs are packaged in MAC frames (80211Pkt), which in turn are encapsulated by AirFrame11p signals. So basically, you should choose the correct message type for your application.
Footnote regarding application behavior:
Technically speaking, these messages would be more correctly placed at the Facilities layer (see e.g. ETSI's spec), since the periodic exchange of messages provides data stored in the facilities layer, which is then used by cITS/VANET applications that run on top. If you need this, look at Artery (as Ventu suggested in the comments).
I'm using Beckhoff's BK9000 (Ethernet TCP/IP Bus Couplers) with other KL blocks to connect the switch. I'd like to choose the switch which fits this bus coupler, but I noticed that there are two choices for the switch, NPN or PNP.
According to the website,
Many modern PLC input cards can be configured and wired to be either 'sinking' or 'sourcing' although it will usually necessitate all inputs on a particular input card being configured the same.
Which switch should I choose? Is BK9000 a sourcing or sinking device? Or doesn't it matter at all?
I'm sorry if I'm asking a silly question. I tried to find more information and tutorial, but couldn't find the practical explanation (most of them were just about the general explanation of PNP/NPN or sourcing/sinking).
The BK9000 is only the coupler and doesn't determine whether it is sinking or sourcing. It is the KL cards you choose that determine it. You can choose versions of the KL cards that are either sourcing (supplying the positive voltage), such as the KL2408 or sinking, such as the KL2488
I have a Simulink model that includes a lot of inter-connected subsystems. A lot of these subsystems are connected to the other with "goto" objects. For verification and documentation purpose, I need to get the complete list of inputs/outputs of each sub-system, and check that the subsystem are connected between them as expected. Checking manually each connection is really time consuming and I often make mistakes doing it. Is there a way (function/script/command) to obtain the list automatically? Thank you very much if you can help me.
Firstly, have you considered using the Simulink Model Advisor to do this? You can create your own custom checks.
Secondly, it is possible to determine which blocks a sub-system (or any other block is connected to)
Selecting a block manually in the model and then running the following, will give you a cell array of all the blocks that the current block is connected to.
connected_to = get_param(gcb,'PortConnectivity')
If the block has 4 inputs, then the connected_to variable will contain 4 items. You can get the Source Block name by doing
srcBlockName = connected_to(1).SrcBlock;
Typically you would work from the outports back through the model to the inports or other source blocks checking what is connected to each.
I'm implementing a small PCI driver for academic purposes, and one thing I'm not clear about if we actually have to provide driver.conf? Different materials which I read (including http://blog.csdn.net/hotsolaris/article/details/1763716), say that for PCI the driver config file is optional, however in my case it seems that pci_config_setup() is successful only with driver.conf provided:
name="mydrv" parent="/pci#0,0/pci8086,2e11"
Then I do:
% add_drv -i 'pciXXXX,YY' mydrv
and it adds in the system with no warning or error messages.
So I assume that some properties of a PCI device can't be derived automatically by the system, e.g. parent bus?
I would appreciate if anybody could shed some light on this. Thanks.
If you look at a random selection of very small files under /kernel/drv for actual physical hardware, you'll see that they almost always only contain the line
ddi_forceattach=1;
Pseudo drivers will have a driver.conf(4) file which reflects their parentage in the system. I really recommend reading that manpage, it goes into good detail about what's required here.