Re: Standardisation - adding 2 bit STBC and Ness to MCS

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Oleksij Rempel]

Hallo all,


> http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness
>
> I have posted 3 patches on the proposal page (see Attachments):
>
> 1. A patch that applies to the Linux kernel v3.7-rc1 to collect the new
> STBC and Ness parameters from a wireless driver, and add them into the
> MCS radiotap field.
> 2. A patch to the Intel wireless driver in the kernel to collect STBC
> and Ness information.
> 3. A patch to wireshark to display STBC and Ness information.
>
> With this I believe we have everything needed to start the 3 week
> comment period.

There is a bit more then 3 week now. I would like to have this approved :)
Are there any thing needed to finish this?

Beside, i have one question about how STBC work. According to differnet 
docs, i assume that:
- STBC is done by sending, at least, two stream with same data in 
different order.
- It means for me, that real use of STBC can be made only on MIMO hardware.
- If 1x1 receiver indicates that it got STBC encoded frame, it dos not 
meant, it would be able to use redundant data from second stream.
- There are fallowing STBC schemes: Alamouti’s
STBC for 2 transmit antennas and orthogonal STBC for 3 and 4 transmit 
antennas.

According to this information, what do we call 1,2 or 3 stream STBC?
Since STBC should have minimal 2 stream, but in same time we have 1x1 
and 2x2 hardware which able to receive and decode STBC stream i assume:
	- RX-STBC1 is for compatibility only. No data redundancy.
	- RX-STBC12 - can be used Alamouti’s schema with 2 streams. Mostly used 
method.
	- RX-STBC123 - is orthogonal schema and not widely used method. Since 
last method use wide spectrum to transmit data comparable to SISO 
stream, it makes almost no sense. But 3-stream method get optimal error 
corect in compare with 2 and 4 strea schemas.

Do this assumptions correct?

PS: My assumptions based on "MIMO Space-Time Block Coding (STBC):
Simulations and Results"
-- 
Regards,
Oleksij

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Johannes Berg]

On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:

> > With this I believe we have everything needed to start the 3 week
> > comment period.

Yeah, I guess there was plenty of time. I would have preferred a
separate thread, but I guess there's little enough traffic on this list
so it doesn't really matter.

> There is a bit more then 3 week now. I would like to have this approved :)
> Are there any thing needed to finish this?

http://www.radiotap.org/Standardisation

johannes

Patches for STBC Standartisation

[Oleksij Rempel]

Here are two series of patches. First are kernel patches
and ath9k driver patch.
Second, is patch for tcpdump.

All of them was tested for 1,2 and 3 stream scenarious.
Sinse i do not have hardware which can recive more than 1 STBC
stream, i did some hacks to to produce this kind of captures.

Oleksij Rempel (3):
  mac80211: add STBC flag for radiotap
  ath9k: remove useless flag conversation.
  ath9k: check for Rx-STBC flag and pass it to ieee80211


-- 
1.8.1.2

[PATCH 1/3] mac80211: add STBC flag for radiotap

[Oleksij Rempel]

Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
---
 include/net/ieee80211_radiotap.h | 7 +++++++
 include/net/mac80211.h           | 4 ++++
 net/mac80211/main.c              | 3 ++-
 net/mac80211/rx.c                | 4 ++++
 net/mac80211/status.c            | 3 ++-
 5 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/include/net/ieee80211_radiotap.h b/include/net/ieee80211_radiotap.h
index c399963..c6d07cb 100644
--- a/include/net/ieee80211_radiotap.h
+++ b/include/net/ieee80211_radiotap.h
@@ -269,6 +269,7 @@ enum ieee80211_radiotap_type {
 #define IEEE80211_RADIOTAP_MCS_HAVE_GI		0x04
 #define IEEE80211_RADIOTAP_MCS_HAVE_FMT		0x08
 #define IEEE80211_RADIOTAP_MCS_HAVE_FEC		0x10
+#define IEEE80211_RADIOTAP_MCS_HAVE_STBC	0x20
 
 #define IEEE80211_RADIOTAP_MCS_BW_MASK		0x03
 #define		IEEE80211_RADIOTAP_MCS_BW_20	0
@@ -278,6 +279,12 @@ enum ieee80211_radiotap_type {
 #define IEEE80211_RADIOTAP_MCS_SGI		0x04
 #define IEEE80211_RADIOTAP_MCS_FMT_GF		0x08
 #define IEEE80211_RADIOTAP_MCS_FEC_LDPC		0x10
+#define IEEE80211_RADIOTAP_MCS_STBC_MASK	0x60
+#define		IEEE80211_RADIOTAP_MCS_STBC_1	1
+#define		IEEE80211_RADIOTAP_MCS_STBC_2	2
+#define		IEEE80211_RADIOTAP_MCS_STBC_3	3
+
+#define IEEE80211_RADIOTAP_MCS_STBC_SHIFT	5
 
 /* For IEEE80211_RADIOTAP_AMPDU_STATUS */
 #define IEEE80211_RADIOTAP_AMPDU_REPORT_ZEROLEN		0x0001
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 04c2d46..2b8faeb 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -805,6 +805,7 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info *info)
  *	on this subframe
  * @RX_FLAG_AMPDU_DELIM_CRC_KNOWN: The delimiter CRC field is known (the CRC
  *	is stored in the @ampdu_delimiter_crc field)
+ * @RX_FLAG_STBC_MASK: STBC 2 bit bitmask. 1 - Nss=1, 2 - Nss=2, 3 - Nss=3 
  */
 enum mac80211_rx_flags {
 	RX_FLAG_MMIC_ERROR		= BIT(0),
@@ -832,8 +833,11 @@ enum mac80211_rx_flags {
 	RX_FLAG_80MHZ			= BIT(23),
 	RX_FLAG_80P80MHZ		= BIT(24),
 	RX_FLAG_160MHZ			= BIT(25),
+	RX_FLAG_STBC_MASK		= BIT(26) | BIT(27),
 };
 
+#define RX_FLAG_STBC_SHIFT		26
+
 /**
  * struct ieee80211_rx_status - receive status
  *
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 8a7bfc4..44191a3 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -589,7 +589,8 @@ struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
 	local->hw.conf.short_frame_max_tx_count = wiphy->retry_short;
 	local->hw.radiotap_mcs_details = IEEE80211_RADIOTAP_MCS_HAVE_MCS |
 					 IEEE80211_RADIOTAP_MCS_HAVE_GI |
-					 IEEE80211_RADIOTAP_MCS_HAVE_BW;
+					 IEEE80211_RADIOTAP_MCS_HAVE_BW |
+					 IEEE80211_RADIOTAP_MCS_HAVE_STBC;
 	local->hw.radiotap_vht_details = IEEE80211_RADIOTAP_VHT_KNOWN_GI |
 					 IEEE80211_RADIOTAP_VHT_KNOWN_BANDWIDTH;
 	local->hw.uapsd_queues = IEEE80211_DEFAULT_UAPSD_QUEUES;
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index c8447af..c6b3c62 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -258,6 +258,7 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local *local,
 	pos += 2;
 
 	if (status->flag & RX_FLAG_HT) {
+		unsigned int stbc = status->flag & RX_FLAG_STBC_MASK;
 		rthdr->it_present |= cpu_to_le32(1 << IEEE80211_RADIOTAP_MCS);
 		*pos++ = local->hw.radiotap_mcs_details;
 		*pos = 0;
@@ -267,6 +268,9 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local *local,
 			*pos |= IEEE80211_RADIOTAP_MCS_BW_40;
 		if (status->flag & RX_FLAG_HT_GF)
 			*pos |= IEEE80211_RADIOTAP_MCS_FMT_GF;
+		if (stbc)
+			*pos |= (stbc >> RX_FLAG_STBC_SHIFT)
+					<< IEEE80211_RADIOTAP_MCS_STBC_SHIFT;
 		pos++;
 		*pos++ = status->rate_idx;
 	}
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index 4343920..41143f8 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -312,7 +312,8 @@ static void ieee80211_add_tx_radiotap_header(struct ieee80211_supported_band
 		rthdr->it_present |= cpu_to_le32(1 << IEEE80211_RADIOTAP_MCS);
 		pos[0] = IEEE80211_RADIOTAP_MCS_HAVE_MCS |
 			 IEEE80211_RADIOTAP_MCS_HAVE_GI |
-			 IEEE80211_RADIOTAP_MCS_HAVE_BW;
+			 IEEE80211_RADIOTAP_MCS_HAVE_BW |
+			 IEEE80211_RADIOTAP_MCS_HAVE_STBC;
 		if (info->status.rates[0].flags & IEEE80211_TX_RC_SHORT_GI)
 			pos[1] |= IEEE80211_RADIOTAP_MCS_SGI;
 		if (info->status.rates[0].flags & IEEE80211_TX_RC_40_MHZ_WIDTH)
-- 
1.8.1.2

[PATCH 2/3] ath9k: remove useless flag conversation.

[Oleksij Rempel]

some flags used only outside of ath9k - In this case we can use
"enum mac80211_rx_flags" and pass it upstream without extra
conversation.

Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
---
 drivers/net/wireless/ath/ath9k/ar9003_mac.c |  5 +++--
 drivers/net/wireless/ath/ath9k/mac.c        | 11 +++++++----
 drivers/net/wireless/ath/ath9k/mac.h        |  1 +
 drivers/net/wireless/ath/ath9k/recv.c       |  5 +----
 4 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
index 301bf72..5163abd 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -469,6 +469,7 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs,
 
 	rxs->rs_status = 0;
 	rxs->rs_flags =  0;
+	rxs->flag =  0;
 
 	rxs->rs_datalen = rxsp->status2 & AR_DataLen;
 	rxs->rs_tstamp =  rxsp->status3;
@@ -493,8 +494,8 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs,
 	rxs->rs_isaggr = (rxsp->status11 & AR_RxAggr) ? 1 : 0;
 	rxs->rs_moreaggr = (rxsp->status11 & AR_RxMoreAggr) ? 1 : 0;
 	rxs->rs_antenna = (MS(rxsp->status4, AR_RxAntenna) & 0x7);
-	rxs->rs_flags  = (rxsp->status4 & AR_GI) ? ATH9K_RX_GI : 0;
-	rxs->rs_flags  |= (rxsp->status4 & AR_2040) ? ATH9K_RX_2040 : 0;
+	rxs->flag  |= (rxsp->status4 & AR_GI) ? RX_FLAG_SHORT_GI : 0;
+	rxs->flag  |= (rxsp->status4 & AR_2040) ? RX_FLAG_40MHZ : 0;
 
 	rxs->evm0 = rxsp->status6;
 	rxs->evm1 = rxsp->status7;
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index 498fee0..a52081d 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -547,6 +547,7 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
 
 	rs->rs_status = 0;
 	rs->rs_flags = 0;
+	rs->flag = 0;
 
 	rs->rs_datalen = ads.ds_rxstatus1 & AR_DataLen;
 	rs->rs_tstamp = ads.AR_RcvTimestamp;
@@ -586,10 +587,12 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
 	rs->rs_moreaggr =
 		(ads.ds_rxstatus8 & AR_RxMoreAggr) ? 1 : 0;
 	rs->rs_antenna = MS(ads.ds_rxstatus3, AR_RxAntenna);
-	rs->rs_flags =
-		(ads.ds_rxstatus3 & AR_GI) ? ATH9K_RX_GI : 0;
-	rs->rs_flags |=
-		(ads.ds_rxstatus3 & AR_2040) ? ATH9K_RX_2040 : 0;
+
+	/* directly mapped flags for ieee80211_rx_status */
+	rs->flag |=
+		(ads.ds_rxstatus3 & AR_GI) ? RX_FLAG_SHORT_GI : 0;
+	rs->flag |=
+		(ads.ds_rxstatus3 & AR_2040) ? RX_FLAG_40MHZ : 0;
 
 	if (ads.ds_rxstatus8 & AR_PreDelimCRCErr)
 		rs->rs_flags |= ATH9K_RX_DELIM_CRC_PRE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h b/drivers/net/wireless/ath/ath9k/mac.h
index 5865f92..3f1e775 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -149,6 +149,7 @@ struct ath_rx_status {
 	u32 evm2;
 	u32 evm3;
 	u32 evm4;
+	u32 flag; /* see enum mac80211_rx_flags */
 };
 
 struct ath_htc_rx_status {
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 8be2b5d..b4b758d 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -868,10 +868,7 @@ static int ath9k_process_rate(struct ath_common *common,
 	if (rx_stats->rs_rate & 0x80) {
 		/* HT rate */
 		rxs->flag |= RX_FLAG_HT;
-		if (rx_stats->rs_flags & ATH9K_RX_2040)
-			rxs->flag |= RX_FLAG_40MHZ;
-		if (rx_stats->rs_flags & ATH9K_RX_GI)
-			rxs->flag |= RX_FLAG_SHORT_GI;
+		rxs->flag |= rx_stats->flag;
 		rxs->rate_idx = rx_stats->rs_rate & 0x7f;
 		return 0;
 	}
-- 
1.8.1.2

[PATCH 3/3] ath9k: check for Rx-STBC flag and pass it to ieee80211

[Oleksij Rempel]

Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
---
 drivers/net/wireless/ath/ath9k/mac.c | 5 +++++
 drivers/net/wireless/ath/ath9k/mac.h | 3 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index a52081d..d055e38 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -593,6 +593,11 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
 		(ads.ds_rxstatus3 & AR_GI) ? RX_FLAG_SHORT_GI : 0;
 	rs->flag |=
 		(ads.ds_rxstatus3 & AR_2040) ? RX_FLAG_40MHZ : 0;
+	if (AR_SREV_9280_20_OR_LATER(ah))
+		rs->flag |=
+			(ads.ds_rxstatus3 & AR_STBC) ?
+				/* we can only Nss=1 STBC */
+				(1 << RX_FLAG_STBC_SHIFT) : 0;
 
 	if (ads.ds_rxstatus8 & AR_PreDelimCRCErr)
 		rs->rs_flags |= ATH9K_RX_DELIM_CRC_PRE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h b/drivers/net/wireless/ath/ath9k/mac.h
index 3f1e775..b02dfce 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -534,7 +534,8 @@ struct ar5416_desc {
 #define AR_2040             0x00000002
 #define AR_Parallel40       0x00000004
 #define AR_Parallel40_S     2
-#define AR_RxStatusRsvd30   0x000000f8
+#define AR_STBC             0x00000008 /* on ar9280 and later */
+#define AR_RxStatusRsvd30   0x000000f0
 #define AR_RxAntenna	    0xffffff00
 #define AR_RxAntenna_S	    8
 
-- 
1.8.1.2

[PATCH] tcpdump: add STBC Rx support

[Oleksij Rempel]

Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
---
 ieee802_11_radio.h | 6 ++++++
 print-802_11.c     | 5 +++++
 2 files changed, 11 insertions(+)

diff --git a/ieee802_11_radio.h b/ieee802_11_radio.h
index 5aff137..65c25df 100644
--- a/ieee802_11_radio.h
+++ b/ieee802_11_radio.h
@@ -277,6 +277,7 @@ enum ieee80211_radiotap_type {
 #define IEEE80211_RADIOTAP_MCS_GUARD_INTERVAL_KNOWN	0x04
 #define IEEE80211_RADIOTAP_MCS_HT_FORMAT_KNOWN		0x08
 #define IEEE80211_RADIOTAP_MCS_FEC_TYPE_KNOWN		0x10
+#define IEEE80211_RADIOTAP_MCS_STBC_KNOWN		0x20
 
 /* For IEEE80211_RADIOTAP_MCS flags */
 #define IEEE80211_RADIOTAP_MCS_BANDWIDTH_MASK	0x03
@@ -287,5 +288,10 @@ enum ieee80211_radiotap_type {
 #define IEEE80211_RADIOTAP_MCS_SHORT_GI		0x04 /* short guard interval */
 #define IEEE80211_RADIOTAP_MCS_HT_GREENFIELD	0x08
 #define IEEE80211_RADIOTAP_MCS_FEC_LDPC		0x10
+#define IEEE80211_RADIOTAP_MCS_STBC_MASK	0x60
+#define		IEEE80211_RADIOTAP_MCS_STBC_1	1
+#define		IEEE80211_RADIOTAP_MCS_STBC_2	2
+#define		IEEE80211_RADIOTAP_MCS_STBC_3	3
+#define IEEE80211_RADIOTAP_MCS_STBC_SHIFT	5
 
 #endif /* _NET_IF_IEEE80211RADIOTAP_H_ */
diff --git a/print-802_11.c b/print-802_11.c
index 97badb9..5f65752 100644
--- a/print-802_11.c
+++ b/print-802_11.c
@@ -2184,6 +2184,11 @@ print_radiotap_field(struct cpack_state *s, u_int32_t bit, u_int8_t *flags,
 				(u2.u8 & IEEE80211_RADIOTAP_MCS_FEC_LDPC) ?
 				"LDPC" : "BCC");
 		}
+		if (u.u8 & IEEE80211_RADIOTAP_MCS_STBC_KNOWN) {
+			printf("RX-STBC%u ",
+				(u2.u8 & IEEE80211_RADIOTAP_MCS_STBC_MASK) >> IEEE80211_RADIOTAP_MCS_STBC_SHIFT);
+		}
+	
 		break;
 		}
 	}
-- 
1.8.1.2

Re: [PATCH] tcpdump: add STBC Rx support

[Guy Harris]

You might want to fork the tcpdump Git repository on GitHub:

	https://github.com/the-tcpdump-group/tcpdump

make your changes, and submit a pull request for the tcpdump repository; that's the preferred way to submit changes to tcpdump (and, *mutatis mutandis*, to libpcap).

Re: [PATCH] tcpdump: add STBC Rx support

[Oleksij Rempel]

Am 03.05.2013 21:58, schrieb Guy Harris:
> You might want to fork the tcpdump Git repository on GitHub:
>
> 	https://github.com/the-tcpdump-group/tcpdump
>
> make your changes, and submit a pull request for the tcpdump repository; that's the preferred way to submit changes to tcpdump (and, *mutatis mutandis*, to libpcap).
>

Ok, i'll do that. I thought is should be posted first on radiotap list 
as part of standardisation process. May be some constructive comments 
and change will come ;)

-- 
Regards,
Oleksij

Patch for radiotap library

[Oleksij Rempel]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

Am 03.05.2013 21:53, schrieb Oleksij Rempel:
> Here are two series of patches. First are kernel patches
> and ath9k driver patch.
> Second, is patch for tcpdump.
>
> All of them was tested for 1,2 and 3 stream scenarious.
> Sinse i do not have hardware which can recive more than 1 STBC
> stream, i did some hacks to to produce this kind of captures.
>
> Oleksij Rempel (3):
>    mac80211: add STBC flag for radiotap
>    ath9k: remove useless flag conversation.
>    ath9k: check for Rx-STBC flag and pass it to ieee80211

One more patch for radiotap lib.

-- 
Regards,
Oleksij

[-- Attachment #2: 0001-radiotap-add-STBC-Rx-fields.patch --]
[-- Type: text/x-patch, Size: 1204 bytes --]

>From cf3cea707b5766d822ae595cc75849efa78cdb1e Mon Sep 17 00:00:00 2001
From: Oleksij Rempel <linux@rempel-privat.de>
Date: Sat, 4 May 2013 08:19:07 +0200
Subject: [PATCH] radiotap: add STBC Rx fields.

Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
---
 radiotap.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/radiotap.h b/radiotap.h
index a566024..2538433 100644
--- a/radiotap.h
+++ b/radiotap.h
@@ -267,6 +267,7 @@ enum ieee80211_radiotap_type {
 #define IEEE80211_RADIOTAP_MCS_HAVE_GI		0x04
 #define IEEE80211_RADIOTAP_MCS_HAVE_FMT		0x08
 #define IEEE80211_RADIOTAP_MCS_HAVE_FEC		0x10
+#define IEEE80211_RADIOTAP_MCS_HAVE_STBC	0x20
 
 #define IEEE80211_RADIOTAP_MCS_BW_MASK		0x03
 #define		IEEE80211_RADIOTAP_MCS_BW_20	0
@@ -276,5 +277,10 @@ enum ieee80211_radiotap_type {
 #define IEEE80211_RADIOTAP_MCS_SGI		0x04
 #define IEEE80211_RADIOTAP_MCS_FMT_GF		0x08
 #define IEEE80211_RADIOTAP_MCS_FEC_LDPC		0x10
+#define IEEE80211_RADIOTAP_MCS_STBC_MASK	0x60
+#define		IEEE80211_RADIOTAP_MCS_STBC_1	1
+#define		IEEE80211_RADIOTAP_MCS_STBC_2	2
+#define		IEEE80211_RADIOTAP_MCS_STBC_3	3
+#define IEEE80211_RADIOTAP_MCS_STBC_SHIFT	5
 
 #endif				/* IEEE80211_RADIOTAP_H */
-- 
1.8.1.2

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Oleksij Rempel]

Am 02.05.2013 22:44, schrieb Johannes Berg:
> On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
>
>>> With this I believe we have everything needed to start the 3 week
>>> comment period.
>
> Yeah, I guess there was plenty of time. I would have preferred a
> separate thread, but I guess there's little enough traffic on this list
> so it doesn't really matter.
>
>> There is a bit more then 3 week now. I would like to have this approved :)
>> Are there any thing needed to finish this?
>
> http://www.radiotap.org/Standardisation
>
> johannes
>

ping.

Johannes, are you the one who says last word on standardisation for 
radiotap?

-- 
Regards,
Oleksij

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Johannes Berg]

On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote:
> Am 02.05.2013 22:44, schrieb Johannes Berg:
> > On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
> >
> >>> With this I believe we have everything needed to start the 3 week
> >>> comment period.
> >
> > Yeah, I guess there was plenty of time. I would have preferred a
> > separate thread, but I guess there's little enough traffic on this list
> > so it doesn't really matter.
> >
> >> There is a bit more then 3 week now. I would like to have this approved :)
> >> Are there any thing needed to finish this?
> >
> > http://www.radiotap.org/Standardisation
> >
> > johannes
> >
> 
> ping.
> 
> Johannes, are you the one who says last word on standardisation for 
> radiotap?

No? I thought the link made that pretty clear.

But since nobody poked holes in this and it's been a long time, I think
you should probably just post "this has been adopted now" ...

johannes

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Johannes Berg]

On Tue, 2013-05-07 at 15:54 +0200, Johannes Berg wrote:
> On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote:
> > Am 02.05.2013 22:44, schrieb Johannes Berg:
> > > On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
> > >
> > >>> With this I believe we have everything needed to start the 3 week
> > >>> comment period.
> > >
> > > Yeah, I guess there was plenty of time. I would have preferred a
> > > separate thread, but I guess there's little enough traffic on this list
> > > so it doesn't really matter.
> > >
> > >> There is a bit more then 3 week now. I would like to have this approved :)
> > >> Are there any thing needed to finish this?
> > >
> > > http://www.radiotap.org/Standardisation
> > >
> > > johannes
> > >
> > 
> > ping.
> > 
> > Johannes, are you the one who says last word on standardisation for 
> > radiotap?
> 
> No? I thought the link made that pretty clear.
> 
> But since nobody poked holes in this and it's been a long time, I think
> you should probably just post "this has been adopted now" ...

Or actually, go to step 5, preferably reposting it as a separate thread.

johannes

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Oleksij Rempel]

Am 07.05.2013 15:55, schrieb Johannes Berg:
> On Tue, 2013-05-07 at 15:54 +0200, Johannes Berg wrote:
>> On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote:
>>> Am 02.05.2013 22:44, schrieb Johannes Berg:
>>>> On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
>>>>
>>>>>> With this I believe we have everything needed to start the 3 week
>>>>>> comment period.
>>>>
>>>> Yeah, I guess there was plenty of time. I would have preferred a
>>>> separate thread, but I guess there's little enough traffic on this list
>>>> so it doesn't really matter.
>>>>
>>>>> There is a bit more then 3 week now. I would like to have this approved :)
>>>>> Are there any thing needed to finish this?
>>>>
>>>> http://www.radiotap.org/Standardisation
>>>>
>>>> johannes
>>>>
>>>
>>> ping.
>>>
>>> Johannes, are you the one who says last word on standardisation for
>>> radiotap?
>>
>> No? I thought the link made that pretty clear.
>>
>> But since nobody poked holes in this and it's been a long time, I think
>> you should probably just post "this has been adopted now" ...
>
> Or actually, go to step 5, preferably reposting it as a separate thread.


Simon,

will you do it? You stared it and did most of the work...


-- 
Regards,
Oleksij

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Jonathan Bither]

On 05/07/2013 09:55 AM, Johannes Berg wrote:
> On Tue, 2013-05-07 at 15:54 +0200, Johannes Berg wrote:
>> On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote:
>>> Am 02.05.2013 22:44, schrieb Johannes Berg:
>>>> On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
>>>>
>>>>>> With this I believe we have everything needed to start the 3 week
>>>>>> comment period.
>>>>
>>>> Yeah, I guess there was plenty of time. I would have preferred a
>>>> separate thread, but I guess there's little enough traffic on this list
>>>> so it doesn't really matter.
>>>>
>>>>> There is a bit more then 3 week now. I would like to have this approved :)
>>>>> Are there any thing needed to finish this?
>>>>
>>>> http://www.radiotap.org/Standardisation
>>>>
>>>> johannes
>>>>
>>>
>>> ping.
>>>
>>> Johannes, are you the one who says last word on standardisation for
>>> radiotap?
>>
>> No? I thought the link made that pretty clear.
>>
>> But since nobody poked holes in this and it's been a long time, I think
>> you should probably just post "this has been adopted now" ...
>
> Or actually, go to step 5, preferably reposting it as a separate thread.
It looks as if someone already proposed this as a suggested field on 
'2012-05-14 23:49:35' without any replies as far as I can tell.
http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness
>
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Oleksij Rempel]

Am 07.05.2013 16:59, schrieb Jonathan Bither:
>
>
> On 05/07/2013 09:55 AM, Johannes Berg wrote:
>> On Tue, 2013-05-07 at 15:54 +0200, Johannes Berg wrote:
>>> On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote:
>>>> Am 02.05.2013 22:44, schrieb Johannes Berg:
>>>>> On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
>>>>>
>>>>>>> With this I believe we have everything needed to start the 3 week
>>>>>>> comment period.
>>>>>
>>>>> Yeah, I guess there was plenty of time. I would have preferred a
>>>>> separate thread, but I guess there's little enough traffic on this
>>>>> list
>>>>> so it doesn't really matter.
>>>>>
>>>>>> There is a bit more then 3 week now. I would like to have this
>>>>>> approved :)
>>>>>> Are there any thing needed to finish this?
>>>>>
>>>>> http://www.radiotap.org/Standardisation
>>>>>
>>>>> johannes
>>>>>
>>>>
>>>> ping.
>>>>
>>>> Johannes, are you the one who says last word on standardisation for
>>>> radiotap?
>>>
>>> No? I thought the link made that pretty clear.
>>>
>>> But since nobody poked holes in this and it's been a long time, I think
>>> you should probably just post "this has been adopted now" ...
>>
>> Or actually, go to step 5, preferably reposting it as a separate thread.
> It looks as if someone already proposed this as a suggested field on
> '2012-05-14 23:49:35' without any replies as far as I can tell.
> http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness

Yes, Simon did it last year. I send this link on my first email...
In my opinion, this should be just ACKed. Every thing what was needed to 
do, is already done.

-- 
Regards,
Oleksij

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Jonathan Bither]

On Tue 07 May 2013 11:03:32 AM EDT, Oleksij Rempel wrote:
> Am 07.05.2013 16:59, schrieb Jonathan Bither:
>>
>>
>> On 05/07/2013 09:55 AM, Johannes Berg wrote:
>>> On Tue, 2013-05-07 at 15:54 +0200, Johannes Berg wrote:
>>>> On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote:
>>>>> Am 02.05.2013 22:44, schrieb Johannes Berg:
>>>>>> On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
>>>>>>
>>>>>>>> With this I believe we have everything needed to start the 3 week
>>>>>>>> comment period.
>>>>>>
>>>>>> Yeah, I guess there was plenty of time. I would have preferred a
>>>>>> separate thread, but I guess there's little enough traffic on this
>>>>>> list
>>>>>> so it doesn't really matter.
>>>>>>
>>>>>>> There is a bit more then 3 week now. I would like to have this
>>>>>>> approved :)
>>>>>>> Are there any thing needed to finish this?
>>>>>>
>>>>>> http://www.radiotap.org/Standardisation
>>>>>>
>>>>>> johannes
>>>>>>
>>>>>
>>>>> ping.
>>>>>
>>>>> Johannes, are you the one who says last word on standardisation for
>>>>> radiotap?
>>>>
>>>> No? I thought the link made that pretty clear.
>>>>
>>>> But since nobody poked holes in this and it's been a long time, I
>>>> think
>>>> you should probably just post "this has been adopted now" ...
>>>
>>> Or actually, go to step 5, preferably reposting it as a separate
>>> thread.
>> It looks as if someone already proposed this as a suggested field on
>> '2012-05-14 23:49:35' without any replies as far as I can tell.
>> http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness
>>
>
> Yes, Simon did it last year. I send this link on my first email...
> In my opinion, this should be just ACKed. Every thing what was needed
> to do, is already done.
>

Whoops, one of those days I guess. Sorry for the noise.

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Simon Barber]

I did post example code as attachments to the suggested-fields page a 
few months ago. Click on 'attachments' to view them. There are 3:

1. Intel wlan driver patch
2. Kernel patch
3. Wireshark patch.

Simon


On 05/01/2013 07:34 AM, Oleksij Rempel wrote:
> Hallo all,
>
>
>> http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness
>>
>>
>> I have posted 3 patches on the proposal page (see Attachments):
>>
>> 1. A patch that applies to the Linux kernel v3.7-rc1 to collect the new
>> STBC and Ness parameters from a wireless driver, and add them into the
>> MCS radiotap field.
>> 2. A patch to the Intel wireless driver in the kernel to collect STBC
>> and Ness information.
>> 3. A patch to wireshark to display STBC and Ness information.
>>
>> With this I believe we have everything needed to start the 3 week
>> comment period.
>
> There is a bit more then 3 week now. I would like to have this approved :)
> Are there any thing needed to finish this?
>
> Beside, i have one question about how STBC work. According to differnet
> docs, i assume that:
> - STBC is done by sending, at least, two stream with same data in
> different order.
> - It means for me, that real use of STBC can be made only on MIMO hardware.
> - If 1x1 receiver indicates that it got STBC encoded frame, it dos not
> meant, it would be able to use redundant data from second stream.
> - There are fallowing STBC schemes: Alamouti’s
> STBC for 2 transmit antennas and orthogonal STBC for 3 and 4 transmit
> antennas.
>
> According to this information, what do we call 1,2 or 3 stream STBC?
> Since STBC should have minimal 2 stream, but in same time we have 1x1
> and 2x2 hardware which able to receive and decode STBC stream i assume:
>      - RX-STBC1 is for compatibility only. No data redundancy.
>      - RX-STBC12 - can be used Alamouti’s schema with 2 streams. Mostly
> used method.
>      - RX-STBC123 - is orthogonal schema and not widely used method.
> Since last method use wide spectrum to transmit data comparable to SISO
> stream, it makes almost no sense. But 3-stream method get optimal error
> corect in compare with 2 and 4 strea schemas.
>
> Do this assumptions correct?
>
> PS: My assumptions based on "MIMO Space-Time Block Coding (STBC):
> Simulations and Results"