Hi,
in the wake of https://gerrit.osmocom.org/1411 I have some more comments on the
code that seem to large for the gerrit edit field.
I said in that patch comment that gprs_rlc_mcs_cps() must check that it isn't
using INVALID enum values in its bitfield calculations. Furthermore:
The bit fields are obtained by modulo calculation on enum values. This seems
unnecessarily complex and error prone, it is hard to figure out for a reader.
The relation is quite direct though, e.g. for EGPRS_MAX_PS_NUM_2 it means that
PS_1 and PS_3 mean + 0, PS_2 means + 1. I wish that were easier to see. It
would be good to prepare that above the switch() and use it below instead of
duplicating the same calculation numerous times.
Thirdly, for enum egprs_puncturing_values, the comment refers to TS 44.060
10.4.8a.3.1, 10.4.8a.2.1, 10.4.8a.1.1. When reading the first time, I saw table
10.4.8a.3.1 reflecting the names found in the table: PS1, PS2 and PS3. And it
appeared that there are values missing. Typically, when we place a spec
reference on an enum in Osmocom code, it means that this enum *exactly*
represents the given table. This enum, however, is "merely" an internal
indicator, later translated into the table's bit values. The enum definitions
should have a comment sort of like "Puncturing scheme values. See
gprs_rlc_mcs_cps()" without TS table references, and TS refs should be with
that function.
It's also not helpful to place references to two more tables in the comment:
the reader is left guessing what the exact relation is. If more than one TS
table is involved, the comment should explain the relation.
Cosmetic: the switch() statement in that function has line breaking
that doesn't match Osmocom coding style, making it even harder to read.
These are things we missed when accepting these changes. It would be nice to
get them fixed at some point.
Thanks!
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Dear Osmocom Community,
[please respect the Reply-To and post all follow-up discussion to this
to openbsc(a)lists.osmocom.org, so we avoid having long threads
cross-posted to several mailing lists.]
>From 2012 to 2016 we were running a series of small, invitation-only
Osmocom Developer Conferences. Access was intentionally restricted
to those community members who have demonstrated an existing track
record of contribution to any of the projects under the Osmocom
umbrella.
This format of a small, tightly knit group of about 20 people has been
successful over the years, and I have received a lot of positive
feedback from past participants.
On the other hand, the Osmocom project has grown in scope and diversity,
and some of those projects don't have all that much relationship to each
other - except being started by people from within the same group.
There's the cellular communications (GSM/GPRS/EDGE/UMTS and hopefully at
some point LTE) protocols which is attracting a lot of professional
users. And then there's pure community projects like rtl-sdr,
OsmocomBB, OsmocomGMR and many other efforts.
Particularly the cellular infrastructure projects (OsmoBTS, OsmoPCU,
OsmoBTS, OsmoNITB, OsmoSGSN, OpenGGSN, OsmoIuh & co) are somehow
"standing out" of the othe projects in the context of having a wider
user bsae, and in that user base also primarily commercial users.
So I'd like to start a discussion on how to possibly change the event
format to accomodate the various interests and parties. I definitely
don't want to loose the "annual meeting of old friends" atmosphere,
while at the same time also opening up to other interested parties.
One idea would be to keep OsmoDevCon as-is and have a separate event
where non-contributing/developing users / sysadmins / system integrators
could also be attending.
Another idea would be to split into a 'user day' and 'developer days'
format. This is something the netfilter developer workshops have been
using for many years, and from my limited insight quite successfully so.
The "user day" is more like a traditional tech conference, with a large
auditorium and talks oriented towards users / sysadmins / integrators of
the software. The "developer days" are the invitation-only part, for
known contributing developers only, similar to what we have at
OsmoDevCon.
Having both events (or both parts of an event) back-to-back has the
advantage that a large number of potential speakers for the 'user day'
are already present, and they don't have to travel yet another time.
One could even structure it further and say we have one user day, one
public 'Osmocom cellular developer day' and then the closed 'OsmoDevCon
classic', maybe reduced from 4 days to 3 or even 2 days only?
What is the general opinion about this?
Are there people lurking on this list who would be interested in
attending a public 'user day' or even 'developer day' about the Osmocom
cellular projects, with presentations and workshops around topics such
as running Osmocom based cellular networks?
In terms of when/where, I would suggest to keep the tradition of April
in Berlin/Germany. But I'm of course very happy if somebody wants to
host it some place else...
Regards, and looking forward to meeting you [again] in 2017,
Harald
--
- 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)
HI.
Pardon the cross-posting, I'm not sure where this question really belongs.
I've been trying to wrap my head around how PDTCH/PACCH/PTCCH activation
works. In osmo-bts-sysmo/oml.c there is pdtch_sapis[] which defines what
got to be activated both in DL and UL directions. Right now it's PDTCH
(UL & DL), PTCCH (DL) and PRACH. Note that PACCH (DL) and PTCCH (UL) are
commented out.
Yet I see code dealing with PACCH in osmo-pcu and corresponding log
messages.
So the question is - how does this works? The PACCH seems to be used so
it's somehow activated but apparently not the same way as PDTCH.
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Hello All,
We are testing GPRS/EGPRS functionality in Multi-TRX(2 TRX) configuration for 2MS and we observed that both the MS are always assigned resources in TRX0. It seems like there is no load balancing done
Across the TRXs.
Similar issue "Bug #1775 LC15: No PDCH allocation across two TRX" is raised on Multi-TRX and its status is "In Progress". Please let us know if any updates on this issue.
Thanks and Regards,
Aravind Sirsikar
Hello All,
We have executed profiling test of two versions of algorithm for decoding compressed bitmap of EPDAN.
>From the results , we see that performance is better in Tree based decoding (Version2 as given below )
Version 1: Bitmap based decoding as present in current master branch ( Function name osmo_t4_decode )
Version 2: Tree based decoding ( Function name decompress_crbb , as proposed in patch "Decompress the CRBB bitmap using tree based approach"<http://lists.osmocom.org/pipermail/osmocom-net-gprs/2016-March/000525.html> )
A sample bitmap taken from a real mobile log is used for the test.
Host execution: Time taken to decode (micro seconds)
Version 1: (Bitmap based decoding) : MIN -17 MAX -19 AVERAGE -17.9
Version 2 (tree based decoding): MIN -4 MAX -13 AVERAGE - 5.2
Target execution: Time taken to decode (micro seconds)
Version 1: (Bitmap based decoding) : MIN -277 MAX -583 AVERAGE - 353
Version 2 (tree based decoding): MIN -67 MAX -86 AVERAGE - 69.8
Regards
Prasad
Dear Developers,
I have a question for you. As you might be knowing. there is a patch now
available for OVS for GTP-U support. When the developers of the patch
submitted it to add to the main branch of OVS, the OVS developers told the
following.
It doesn't look like upstream Linux has a GTP implementation. Because
our usual workflow is to get code upstream first, you should start by
submitting the kernel patches against net-next when that tree is open (I
don't follow netdev, so I have no idea when that is). Then, once the
GTP code is upstream, we can get it into OVS here.
So, is the upstream Linux having support for GTP now? I am asking this
because I am not certain about what upstream Linux means. If you say that
upstream Linux has support for GTP-U, then I can ask the patch developers
to port it for the latest version of OVS and add it to the main branch.
Best Regards,
Ashish Kurian
Hello All,
We are testing GPRS/EGPRS functionality in Multi-TRX(2 TRX) configuration for 2MS and we observed that both the MS are always assigned resources in TRX0. It seems like there is no load balancing done
Across the TRXs.
Similar issue "Bug #1775 LC15: No PDCH allocation across two TRX" is raised on Multi-TRX and its status is "In Progress". Please let us know if any updates on this issue.
Thanks and Regards,
Mrinal
Hi All
I have added IPv6 support to OpenGGSN and if anybody is interested I will gladly make my patch available. It definitely needs more testing and perhaps a bit of cleanup, but currently it can do 4-in-4, 6-in-4, 4-in-6 and 6-in-6.
Gerrie
Hi
I’m Bjørn, I work for Telenor Digital. We’re running a live experimental network (called “loltel” :-) that is technically operating as a full stack MVNO (mobile virtual network operator), renting network access from Telenor Norway. It’s mostly but not exclusively based on open source components. When we started up about two years ago we considered using OpenGGSN, but couldn’t figure out how to get it into an operational state and we couldn’t find anyone to help us, so we chose a commercial vendor instead.
But today we’re again thinking of using OpenGGSN for an experiment, possibly in our live network. Are there anyone on this list with experiences either with running it in a live network, or with thoughts about how to do it / what would be necessary to get the job done? We’d love to have a discussion with you.
Hope to hear from you soon.
Best wishes
Bjørn
--
Bjørn Remseth --- Senior Software Engineer
(+47) 47900184 | rmz(a)comoyo.com <mailto:ane@comoyo.com> | www.comoyo.com <http://www.comoyo.com/>