[libosmocore PATCH 1/4] protocol/gsm_12_21.h: Add the Manufacturer Attribute ID O_REDUCEPOWER.
5 May
2014
5 May
'14
4:04 p.m.
From: Álvaro Neira Ayuso <anayuso(a)sysmocom.de>
Signed-off-by: Alvaro Neira Ayuso <anayuso(a)sysmocom.de>
---
include/osmocom/gsm/protocol/gsm_12_21.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/osmocom/gsm/protocol/gsm_12_21.h
b/include/osmocom/gsm/protocol/gsm_12_21.h
index 694df93..b1725d5 100644
--- a/include/osmocom/gsm/protocol/gsm_12_21.h
+++ b/include/osmocom/gsm/protocol/gsm_12_21.h
@@ -486,6 +486,8 @@ enum abis_nm_attr {
NM_ATT_BS11_ANT_TYPE = 0xf4,
NM_ATT_BS11_PLL_MODE = 0xfc,
NM_ATT_BS11_PASSWORD = 0xfd,
+
+ NM_ATT_O_REDUCEPOWER = 0x01,
};
#define NM_ATT_BS11_FILE_DATA NM_ATT_EVENT_TYPE
--
1.7.10.4
15 May
15 May
9:55 p.m.
New subject: [libosmocore PATCH 1/4] protocol/gsm_12_21.h: Add the Manufacturer Attribute ID O_REDUCEPOWER.
On Mon, May 05, 2014 at 04:04:02PM +0200, Alvaro Neira Ayuso wrote:
diff --git a/include/osmocom/gsm/protocol/gsm_12_21.h
b/include/osmocom/gsm/protocol/gsm_12_21.h
index 694df93..b1725d5 100644
--- a/include/osmocom/gsm/protocol/gsm_12_21.h
+++ b/include/osmocom/gsm/protocol/gsm_12_21.h
@@ -486,6 +486,8 @@ enum abis_nm_attr {
NM_ATT_BS11_ANT_TYPE = 0xf4,
NM_ATT_BS11_PLL_MODE = 0xfc,
NM_ATT_BS11_PASSWORD = 0xfd,
+
+ NM_ATT_O_REDUCEPOWER = 0x01,
okay, added it. The sorting was already inconsistent. Either
group by source (spec, BS11, ipa, osmocom) or sort by value.
No action from you is required though.
19 May
19 May
11:48 a.m.
New subject: [libosmocore PATCH 1/4] protocol/gsm_12_21.h: Add the Manufacturer Attribute ID O_REDUCEPOWER.
Hi Alvaro,
I had to modifiy/update this patch by the attached patch, it contains a
quite verbose message stating the rationale why.
The corresponding code out of osmo-bts hd to be reverted, I will follow
up with more explanations as to why.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
1:49 p.m.
New subject: [libosmocore PATCH 1/4] protocol/gsm_12_21.h: Add the Manufacturer Attribute ID O_REDUCEPOWER.
On Mon, May 19, 2014 at 11:48:47AM +0200, Harald Welte wrote:
Rename NM_ATT_O_REDUCEPOWER to
NM_ATT_OSMO_REDUCEPOWER, which
makes it more clear that this is an osmcoom specific attribute.
Also, we cannot simply overload 0x01 as an already defined OML
attribute. The problem is quite simple: When we use abis_nm_att_tlvdef
during the TLV parse, 0x01 will match to NM_ATT_ABIS_CHANNEL,
which is defined as { TLV_TYPE_FIXED, 3 }.
But we already do have overlap. At least between BS11 and ipaccess.
How is it different from GSM to osmocom? We could argue that the
vendor values should not be in the gsm enum but sit somewhere else?
Can you please elaborate?
I'm using 0xfe for the attribute, as 0xfe
doesn't overlap with the IPA
specific attribues (and we might want to combine/merge the 12.21 plus
IPA plus osmocom spefici attributes)
typo(s). :)
3:44 p.m.
New subject: [libosmocore PATCH 1/4] protocol/gsm_12_21.h: Add the Manufacturer Attribute ID O_REDUCEPOWER.
Hi Holger,
On Mon, May 19, 2014 at 01:49:27PM +0200, Holger Hans Peter Freyther wrote:
my apologies. well, as long as people can unserstand what I read, I
don't really think it is the most useful way to use my time to re-read
everything in order to spot + fix them.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
On Mon, May 19, 2014 at 11:48:47AM +0200, Harald Welte
wrote:
Yes, this is not an issue as e.g. openbsc uses the tlv_def_patch()
function to merge the generic 12.21 ones with either the BS11 ones, or
the ip.access ones. There is no overlapping in those respective sets.
You can of couse not merge all three of them. During the patching, the
vendor-specific IEI can override a 12.21 IEI / TLV definition. I think
Siemens has in some cases used TV where the spec says TV16 or vice
versa.
But even if it was the intention of the osmocom IEI to override the
NM_ATT_ABIS_CHANNEL, then the code would first have to create a patched
tlv definition table, and then use tlv_parse with that patched table,
rather than the pristine 12.21 one.
Rename NM_ATT_O_REDUCEPOWER to
NM_ATT_OSMO_REDUCEPOWER, which
makes it more clear that this is an osmcoom specific attribute.
Also, we cannot simply overload 0x01 as an already defined OML
attribute. The problem is quite simple: When we use abis_nm_att_tlvdef
during the TLV parse, 0x01 will match to NM_ATT_ABIS_CHANNEL,
which is defined as { TLV_TYPE_FIXED, 3 }.
But we already do have overlap. At least between BS11 and ipaccess.
How is it different from GSM to osmocom? We could argue that the vendor values should not be in
the gsm enum
but sit somewhere else?
That might be an option, but its a mere difference in style. If they're
all in one large enum, one can at least see their values/ranges in one
spot.
I'm using
0xfe for the attribute, as 0xfe doesn't overlap with the IPA
specific attribues (and we might want to combine/merge the 12.21 plus
IPA plus osmocom spefici attributes)
typo(s). :)
4:03 p.m.
New subject: [libosmocore PATCH 1/4] protocol/gsm_12_21.h: Add the Manufacturer Attribute ID O_REDUCEPOWER.
On Mon, May 19, 2014 at 03:44:00PM +0200, Harald Welte wrote:
Yes, this is not an issue as e.g. openbsc uses the
tlv_def_patch()
function to merge the generic 12.21 ones with either the BS11 ones, or
the ip.access ones. There is no overlapping in those respective sets.
You can of couse not merge all three of them. During the patching, the
vendor-specific IEI can override a 12.21 IEI / TLV definition. I think
Siemens has in some cases used TV where the spec says TV16 or vice
versa.
But even if it was the intention of the osmocom IEI to override the
NM_ATT_ABIS_CHANNEL, then the code would first have to create a patched
tlv definition table, and then use tlv_parse with that patched table,
rather than the pristine 12.21 one.
My intention of starting with using 0x1 was for the usage in vendor
defined messages. I didn't intend to use these values to add IEs to
existing GSM 12.21 messages. So maybe this is an argument to move the
enum somewhere else.
I didn't think of the tlv_ table for this enum and didn't notice it
in the review. From my point of view I would favor to move this value
into a new enum and introduce a new TLV table for these manufacturer
messages?
3639
days inactive
3653
days old
5 comments
3 participants
participants (3)
-
Alvaro Neira Ayuso -
Harald Welte -
Holger Hans Peter Freyther