From laforge at gnumonks.org Tue Dec 31 14:28:05 2013 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 31 Dec 2013 15:28:05 +0100 Subject: OsmoDevCon 2014 / Date / Venue In-Reply-To: <20131130135720.GI3133@nataraja.gnumonks.org> References: <20131105155825.GK12353@nataraja.gnumonks.org> <20131130135720.GI3133@nataraja.gnumonks.org> Message-ID: <20131231142805.GM13435@nataraja.gnumonks.org> Dear all, just a quick reminder: On Sat, Nov 30, 2013 at 02:57:20PM +0100, Harald Welte wrote: > Please make sure to add your name to the list at > https://openbsc.osmocom.org/trac/wiki/OsmoDevCon2014 until December > 31st (latest). If you don't have a wiki account, ask somebody who has > one, apply for a wiki account or send an e-mail to me. so today is the last chance to indicate your intrest in attending OsmoDevCon. I'm surprised to not have seen the following names in the list: pablo, peter, nion, steve-m, dmitry, kaber. It would be great to have you around again this year. Looking forward to meeting all of you again! Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Tue Dec 31 14:39:37 2013 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 31 Dec 2013 15:39:37 +0100 Subject: 30C3 aftermath Message-ID: <20131231143937.GN13435@nataraja.gnumonks.org> Hi all, first I'd like to thank those who have volunteered to install and operate the 30C3 event network. As I wasn't involved myself, I am not too exhausted to already think about improvements for future events (31C3, ...) first some smaller single-line topics: * more sim cards (easy) * Java SIM cards (easy in qty >> 1000, which we need anyway) * handover to neighbor cells in overload situations * late assignment to keep incompleted calls from taking up a TCH = audio broadcast = I did some brainstorming with Peter and Holger about the idea to assign all phones interested in listening to the audio stream to the same TCH / timeslot on any given BTS. This is highly experimental and non-standard, but I think we can make it work by using late assignment and ignoring the 100% bit errors in uplink. It's yet TBD how phones would ever release from the call, but we can probalby do something like sending a continuous flow of RELEASE COMPLETE on the SACCH cycling over all 8 LAPDm sequence numbers. The question is: Is it worth it? Are people really listening to lectures using GSM (bad quality, ...)? And if yes, should we simply disable this feature on GSM to make room for more important stuff? = network structure / capacity = To increase capacity, we can either get our hands on hardware with many more TRX, or we can reduce the cell size and deploy more sysmoBTS 1002. The latter would definitely be possible from the sysmocom point-of-view. The former would mean that we can obtain a sufficient number of multi-TRX BTSs. If we make smaller cells, this would mean that the BTSs would be * PoE powered * have no PA/LNA * operate with reduced tx power (20mW?) and high rxlev_access_min * use directly attached small rubber antennas I like that approach as it simplifies the setup. No power supplies, no antenna cabling, no large wooden boards, ... - it would in the end be very similar to the the wifi APs or the DECT 'antennas'. Any thoughts? Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Tue Dec 31 19:13:15 2013 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 31 Dec 2013 20:13:15 +0100 Subject: 30C3 aftermath In-Reply-To: <20131231143937.GN13435@nataraja.gnumonks.org> References: <20131231143937.GN13435@nataraja.gnumonks.org> Message-ID: Hi, > = audio broadcast = > > [snip] > > The question is: Is it worth it? Are people really listening to > lectures using GSM (bad quality, ...)? And if yes, should we simply > disable this feature on GSM to make room for more important stuff? People are definitely using it and I think it's a perfectly valid use case and we should not block it (at least not comlpetely. We could for example block it is our last TCH for eg). Quality is not always the best, but speaking from experience, bad english audio is more understandable than german. I think that although it'd be a nice hack, other solutions could be better and handle more use case : - Use of TCH/H with AMR-HR - Smaller cell - Multi TRX > = network structure / capacity = > > To increase capacity, we can either get our hands on hardware with many > more TRX, or we can reduce the cell size and deploy more sysmoBTS 1002. > The latter would definitely be possible from the sysmocom point-of-view. > The former would mean that we can obtain a sufficient number of > multi-TRX BTSs. > > If we make smaller cells, this would mean that the BTSs would be > * PoE powered > * have no PA/LNA > * operate with reduced tx power (20mW?) and high rxlev_access_min > * use directly attached small rubber antennas > > I like that approach as it simplifies the setup. No power supplies, no > antenna cabling, no large wooden boards, ... - it would in the end be > very similar to the the wifi APs or the DECT 'antennas'. > > Any thoughts? Smaller cells to offload busy areas is definitely the way to go IMHO, but I wouldn't drop the large cells all together. The CCH is rather large and covering all corners of it with small low power cell would not be that easy especially frequency planning when the propagation changes quite drastically between an empty venue and one with 9k people in it ... Also, there isn't PoE everywhere. This years they had quite a variety of switches, some with PoE, some with PoE+ and some with nothing so each time we either need to find power or we'd need to put injectors (which requires access to the patch room which would need more NOC coordination and even then AFAICT some of them are only accessible with the help of CCH staff). So I'd probably go for 3 large cells (one of them in the MOC, easier to setup stuff there) and the two others at opposite end of the CCH on different floors, or in the middle (like the one we put in with the bidirectional patch). Then the rest small cells distributed in the crowded areas (main halls + hackcenter + lounge mainly) becasue it's true it's very practical. The cell we had in the catwalk/balcony above Hall 3 was really simple to install/remove. I also wouldn't bother with nanoBTS at all, we haven't used them this year at all and it was really stable on day 2,3,4 once we fixed that nasty SMS bug. We'd need to review the logs to see which BTS experienced the more "No free channel" messages. I also think multi-TRX could be fun (possibly using fairwaves HW), but we can run out of ARFCN easily. It would be nice if we could sync the L1 of the BTS and use "shared ARFCN" where for eg one TS is used by one BTS and another for another BTS (dynamically of course so the capacity self-adapts). Cheers, Sylvain From alexander.chemeris at gmail.com Tue Dec 31 21:44:44 2013 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Wed, 1 Jan 2014 01:44:44 +0400 Subject: 30C3 aftermath In-Reply-To: References: <20131231143937.GN13435@nataraja.gnumonks.org> Message-ID: Happy New Year! On Tue, Dec 31, 2013 at 11:13 PM, Sylvain Munaut <246tnt at gmail.com> wrote: >> = network structure / capacity = >> > I also think multi-TRX could be fun (possibly using fairwaves HW), but > we can run out of ARFCN easily. It would be nice if we could sync the > L1 of the BTS and use "shared ARFCN" where for eg one TS is used by > one BTS and another for another BTS (dynamically of course so the > capacity self-adapts). I also wanted to mention that by the 31C3 we should have multi-TRX hardware and we would be happy to donate what we have by that time. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ??? ??????? http://fairwaves.ru