IEEE 802.11p / p1609.4
109 views
Skip to first unread message
Pinto Pinto
May 4, 2011, 9:56:29 AM5/4/11
to omn...@googlegroups.com
Dear all,
as far as i have understood from reading the source files of the Ieee80211NewMac regarding the 802.11p, only the basic 802.11 DCF functions are implemented and not the extensions regarding the IEEE P1609.4 / WAVE (i.e. the channel access process described in this paper in Figure 3).
Is there anyone else working on 802.11p/WAVE simulations?
bye
pintoX
as far as i have understood from reading the source files of the Ieee80211NewMac regarding the 802.11p, only the basic 802.11 DCF functions are implemented and not the extensions regarding the IEEE P1609.4 / WAVE (i.e. the channel access process described in this paper in Figure 3).
Is there anyone else working on 802.11p/WAVE simulations?
bye
pintoX
Skidder
May 9, 2011, 8:20:38 AM5/9/11
to omnetpp
Hi pintoX,
I use a modified Mac80211 for 802.11p simulation (using OFDM BER model
and EDCA Mac settings). This gives a single-queue system which is not
yet P1609.4 compliant, then we would have to implement four queues,
internal contention and the channel-hopping between CCH and SCH. As
for my research this is not relevant but there is a need for such a
model if we want to simulate mixed traffic.
But you raise a good point!
greets,
Martijn
On May 4, 3:56 pm, Pinto Pinto <pintox...@gmail.com> wrote:
> Dear all,
> as far as i have understood from reading the source files of the
> Ieee80211NewMac regarding the 802.11p, only the basic 802.11 DCF functions
> are implemented and not the extensions regarding the IEEE P1609.4 / WAVE
> (i.e. the channel access process described in
> this<http://www.csie.ntpu.edu.tw/%7Eyschen/course/96-2/Wireless/papers/MAC...>paper
I use a modified Mac80211 for 802.11p simulation (using OFDM BER model
and EDCA Mac settings). This gives a single-queue system which is not
yet P1609.4 compliant, then we would have to implement four queues,
internal contention and the channel-hopping between CCH and SCH. As
for my research this is not relevant but there is a need for such a
model if we want to simulate mixed traffic.
But you raise a good point!
greets,
Martijn
On May 4, 3:56 pm, Pinto Pinto <pintox...@gmail.com> wrote:
> Dear all,
> as far as i have understood from reading the source files of the
> Ieee80211NewMac regarding the 802.11p, only the basic 802.11 DCF functions
> are implemented and not the extensions regarding the IEEE P1609.4 / WAVE
> (i.e. the channel access process described in
Pinto Pinto
May 10, 2011, 6:12:19 AM5/10/11
to omn...@googlegroups.com
Hi Martijn,
thanks for your reply, it's nice to hear that there are others working on the same subject.
In the latest version of INETMANET there is an implementation of 802.11p in the NewRadio and NewMac modules ad i'm trying to extend it to the P1609.4 protocol, but i'm having some problems :P
Since that protocol uses two intervals, one for CCH and one for SCH (each one using the 802.11 DCF contention mechanisms), i'm guessing that it should use two queues, one for the CCH messages (WSA, WSMP) and one for the SCH packets (IP, etc) - thus two mgmt modules? Currently i am working only on the SCH (CCH only sends the beacon) and i'm trying to achieve to keep the last packet on the SCH in the queue for transmission in the next SCH period (and not in the CCH). It's a very simplistic approach that i use for now, but we'll see in the future!
Anyone with any ideas is welcomed to help :)
bye
pintoX
thanks for your reply, it's nice to hear that there are others working on the same subject.
In the latest version of INETMANET there is an implementation of 802.11p in the NewRadio and NewMac modules ad i'm trying to extend it to the P1609.4 protocol, but i'm having some problems :P
Since that protocol uses two intervals, one for CCH and one for SCH (each one using the 802.11 DCF contention mechanisms), i'm guessing that it should use two queues, one for the CCH messages (WSA, WSMP) and one for the SCH packets (IP, etc) - thus two mgmt modules? Currently i am working only on the SCH (CCH only sends the beacon) and i'm trying to achieve to keep the last packet on the SCH in the queue for transmission in the next SCH period (and not in the CCH). It's a very simplistic approach that i use for now, but we'll see in the future!
Anyone with any ideas is welcomed to help :)
bye
pintoX
--
You received this message because you are subscribed to the Google Groups "omnetpp" group.
To post to this group, send email to omn...@googlegroups.com.
To unsubscribe from this group, send email to omnetpp+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/omnetpp?hl=en.
Reply all
Reply to author
Forward
0 new messages