This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Rajitha peiris raji.oshin at hotmail.comHi all I have got trough the pcs 1900 nano bts if you have any doubts pls let me ... and these days I am trying to resolves OML issues with RBS 2308 ericson bts Thank you very much Regards Rajitha peiris Sent from my iPhone On Feb 24, 2017, at 9:42 PM, "openbsc-request at lists.osmocom.org<mailto:openbsc-request at lists.osmocom.org>" <openbsc-request at lists.osmocom.org<mailto:openbsc-request at lists.osmocom.org>> wrote: Send OpenBSC mailing list submissions to openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org> To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request at lists.osmocom.org<mailto:openbsc-request at lists.osmocom.org> You can reach the person managing the list at openbsc-owner at lists.osmocom.org<mailto:openbsc-owner at lists.osmocom.org> When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." Today's Topics: 1. Re: Ki and OPC values change when programming MCC and MNC (Holger Freyther) 2. Re: Virtual layer 1 - Questions (Harald Welte) 3. OsmoHLR and IPA unit id (Neels Hofmeyr) 4. Re: Handover and load balancing on SysmoBTS 2050 (Keith) 5. Re: OsmoHLR and IPA unit id (Harald Welte) 6. Re: Handover and load balancing on SysmoBTS 2050 (Keith) ---------------------------------------------------------------------- Message: 1 Date: Thu, 23 Feb 2017 15:25:56 +0700 From: Holger Freyther <holger at freyther.de<mailto:holger at freyther.de>> To: Neels Hofmeyr <nhofmeyr at sysmocom.de<mailto:nhofmeyr at sysmocom.de>> Cc: "openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>" <openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>> Subject: Re: Ki and OPC values change when programming MCC and MNC Message-ID: <31579AC7-F837-49F1-9EDC-C0B8D2CCC85C at freyther.de<mailto:31579AC7-F837-49F1-9EDC-C0B8D2CCC85C at freyther.de>> Content-Type: text/plain; charset=us-ascii On 23 Feb 2017, at 09:53, Neels Hofmeyr <nhofmeyr at sysmocom.de<mailto:nhofmeyr at sysmocom.de>> wrote: On Wed, Feb 22, 2017 at 05:06:20PM +0100, Sylvain Munaut wrote: --help will tell you defaults for Ki and OPC is to randomize ... Ah, indeed, I never saw that. Could also be misunderstood. IMHO it should say right at the top that you normally want to pass -k and -o when calling pysim. After all, none of the other options do that. anyway... "normally".. for the batch mode as used at XC3 events the "normal" is to generate a random KI, you wouldn't want to do that by hand 4k times. :) holger ------------------------------ Message: 2 Date: Thu, 23 Feb 2017 15:41:24 +0100 From: Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>> To: Sebastian Stumpf <sebastian.stumpf87 at googlemail.com<mailto:sebastian.stumpf87 at googlemail.com>> Cc: openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>, baseband-devel at lists.osmocom.org<mailto:baseband-devel at lists.osmocom.org> Subject: Re: Virtual layer 1 - Questions Message-ID: <20170223144124.mdba7w7avdujy23g at nataraja> Content-Type: text/plain; charset=us-ascii Hi Sebastian, On Sun, Feb 19, 2017 at 06:16:01PM +0100, Sebastian Stumpf wrote: I also see that the RACH requesets all are sent with a bogus frame number: 42. This will not work. The RACH request needs to be sent with the current frame number at the time being. I fixed that and calculate the proper rach fn like in https://github.com/osmocom/osmocom-bb/blob/master/src/target/firmware/layer1/prim_rach.c#L137-L151 good. Also, RACH retransmissions are happening way too quick. Calculating a proper frame number didn't fix the fast retransmissions. They are caused by sending the channel request over the virtual um immediately after getting the rach-request from layer23. Thus also the rach-confirm is sent to l23 immediately, so layer23 thinks "oh fine its already transmitted" and will generate the next rach-request for my layer 1. i see. the confirmation should probably be delayed somehow. As a quick intermediate hack you might simply add a timer. I think one can do without on the MS side, but then the BTS must basically queue the incoming frames until the respective frame number indicated in the frame matches the current frame number. I think to fix the problem with the quick retransmission , I need some type of scheduling. Because if I queue the incoming uplink-msgs in the bts-virtual-layer1 instead, I don't know when they are processed on the ms side and thus don't know when to send the rach-confirm to layer23... My idea for a simple scheduler would be: -- no timing and timer interrupts on ms side, but just set the current fn in the ms state each time we receive a message on downlink to the fn of the received message, which is accessible in the gsmtap header. yes, that makes sense. -- queue the outgoing uplink messages with their confirm callback to l2 and process all that with a smaller fn than the current fn in the scheduling function. yes, but please keep in mind that the frame number is wrapping every so often, so "smaller" must consider that modulo-arithmetic, or you will (after fn wrap) have pending downlink messages for much higher fn which are not sent as the wrapped fn is now very small. -- calling the scheduling function each time we receive a msg on downlink (so I do not need to handle timer interrupts) yes. I think it is reasonable to not have any actual timers on the ms side and always depend on the frame numbers in the downlink messages from the BTS. After all, in the worst case you have periodic messages like the BCCH messages that can be used to update the fn. I hope that will be sufficent and try it out tomorrow. I am a bit afraid of trouble caused by the frame number skipping values with the upper incrementation logic. I don't think skips are that problematic. But then, I haven't tried it ;) -- - Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 3 Date: Fri, 24 Feb 2017 06:43:26 +0100 From: Neels Hofmeyr <nhofmeyr at sysmocom.de<mailto:nhofmeyr at sysmocom.de>> To: openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org> Subject: OsmoHLR and IPA unit id Message-ID: <20170224054326.GB1368 at my.box<mailto:20170224054326.GB1368 at my.box>> Content-Type: text/plain; charset="us-ascii" I just ran my first tests of both OsmoNITB and OsmoSGSN connecting to OsmoHLR. It turns out OsmoHLR uses the ipaccess_unit data a.k.a. CCM (whatever CCM means) to route GSUP replies back to its sender. It looks like "NAME-00-00-00-00-00-00". However, all of our GSUP client code simply sets the unit id to: "SGSN-00-00-00-00-00-00". The result is that the VLR never receives an UPDATE LOCATION RESULT, because it is sent to the SGSN instead, since that was the first one to say that it is "SGSN-00...". I would extend the GSUP clients to allow setting an ID from VTY, or maybe a random ID. At this point it would suffice to make the MSC side say it is "MSC-00-00-00-00-00-00" but that's beside the point. Do we really want to do that? Any peer could come along and say it is someone else, very easy to misconfigure (and not very security sensitive when thinking of OAP -- which we're not using but maybe we will one day). For some messages, OsmoHLR uses the conn pointer from msg rx to route the response back -- that works. AFAICT it just receives messages and replies to them right away (but haven't seen / understood all of it). For the case of the UPDATE LOCATION RESULT, it would also be possible to use the same conn pointer, but the code chooses to resolve by id and then sends to the wrong peer. If it used the peer's IP address and port instead, things would work out. With the attached and possibly very stupid patch, OsmoHLR works for me with both MSC and SGSN talking to it even though they have identical IPA IDs: I bluntly store the conn in struct lu_operation and re-use it later. Which way shall we resolve this? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-RFC-add-the-osmo_gsup_conn-directly-to-the-lu_operat.patch Type: text/x-diff Size: 2550 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170224/121d8d06/attachment-0002.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170224/121d8d06/attachment-0003.bin> ------------------------------ Message: 4 Date: Fri, 24 Feb 2017 16:42:35 +0100 From: Keith <keith at rhizomatica.org<mailto:keith at rhizomatica.org>> To: Alexander Chemeris <alexander.chemeris at gmail.com<mailto:alexander.chemeris at gmail.com>> Cc: OpenBSC Mailing List <openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>> Subject: Re: Handover and load balancing on SysmoBTS 2050 Message-ID: <39e245c4-ba1a-600b-8e38-cb300c10133f at rhizomatica.org<mailto:39e245c4-ba1a-600b-8e38-cb300c10133f at rhizomatica.org>> Content-Type: text/plain; charset=utf-8 Hi Alexander, seeing as how you came in on the thread, as a side topic, you may have noticed I mentioned meas_json and meas_web in the OP. I fixed up a small thing with meas_json that was producing unparseable json in the neighbours array. I also did some stuff server side to filter for either SDCCH or TCH, although I think I would make this a clientside javascript filter option, rather than running multiple websocketd I added the neighbour levels to the displayed data. I hardcoded the ARFCNs for the site in question, but I would make that happen dynamically. I found this quite useful for monitoring in relation to analysis on this site and the would-be handover scenario. I'm wondering what to do with this work. Should I make a commit of meas_json to master? In that case I would appreciate some minor help getting the Makefile right. Maybe meas_json is not a candidate for the master branch, as it doesn't currently do anything particularly useful without the external dependencies, ie meas_web and websocketd or alternative. I can publish my work on meas_web to github. Keith. ------------------------------ Message: 5 Date: Fri, 24 Feb 2017 16:53:03 +0100 From: Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>> To: Neels Hofmeyr <nhofmeyr at sysmocom.de<mailto:nhofmeyr at sysmocom.de>> Cc: openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org> Subject: Re: OsmoHLR and IPA unit id Message-ID: <20170224155303.tuidxovd4qbzp5go at nataraja> Content-Type: text/plain; charset=us-ascii Hi Neels, IPA CCM made sense on the Abis interface, where each BTS reports with its unit_id and MAC address. I'm not quite sure how much sense that makes in the core network. I also don't know if existing implementations of e.g. A interface over IPA multiplex actually use it. In terms of future outlook, the MSC/VLR/SGSN should register at the HLR with some kind of identity. In MAP, it is the SCCP Address that is used for this purpose. In absence of SCCP on GSUP, I used the CCM identity as a replacement. However, it is used as an opaque string, so that any GSUP/MAP gateway might simply translate the SCCP address into a string of its choosing, and then talk to OsmoHLR. OsmoHLR would then simply do a strcmp() on the string to match the identity. Sooner or later, OsmoHLR will have to store this identity in the database, e.g. for imlpementing message-waiting-lists of SMSCs in case of MT-SMS from real SMSCs. All-in-all, I think the string approach is not too bad in terms of keeping GSUP simple while having a clan approach to interworkng with MAP. On Fri, Feb 24, 2017 at 06:43:26AM +0100, Neels Hofmeyr wrote: I just ran my first tests of both OsmoNITB and OsmoSGSN connecting to OsmoHLR. It turns out OsmoHLR uses the ipaccess_unit data a.k.a. CCM (whatever CCM means) to route GSUP replies back to its sender. It looks like "NAME-00-00-00-00-00-00". However, all of our GSUP client code simply sets the unit id to: "SGSN-00-00-00-00-00-00". The result is that the VLR never receives an UPDATE LOCATION RESULT, because it is sent to the SGSN instead, since that was the first one to say that it is "SGSN-00...". this is of course not good. I would extend the GSUP clients to allow setting an ID from VTY, or maybe a random ID. At this point it would suffice to make the MSC side say it is "MSC-00-00-00-00-00-00" but that's beside the point. A random ID would not be permissible, as it has to be persistent accross MSC/VLR/HLR re-starts, in order to make above-mentioned mechanisms working. I would say, why not simply use the same approach as in OsmoBTS, i.e. use the MAC address (together with the MSC or SGSN prefix). The MAC address is unlikely to change frequently or on short notice. For people who know what they're doing, we can have a VTY command to override the identity with a manually-specified string. If that option is not set, the default "(SGSN|MSC)-MAC" is used. Do we really want to do that? Any peer could come along and say it is someone else, very easy to misconfigure (and not very security sensitive when thinking of OAP -- which we're not using but maybe we will one day). I don't think we are aiming for anyone to use those protocols on public[ly accessible] networks. There's no message authentication or other cryptographic protection anyway. OAP seems like a funny but futile minor obstacle, but nothing that can provide any reasonable level of security. For some messages, OsmoHLR uses the conn pointer from msg rx to route the response back -- that works. This should be done in all request-response style procedures, I think. AFAICT it just receives messages and replies to them right away (but haven't seen / understood all of it). For the case of the UPDATE LOCATION RESULT, it would also be possible to use the same conn pointer, but the code chooses to resolve by id and then sends to the wrong peer. If it used the peer's IP address and port instead, things would work out. Looking up by ID would also work in case meanwhile the old connection has died and a new connection has been established With the attached and possibly very stupid patch, OsmoHLR works for me with both MSC and SGSN talking to it even though they have identical IPA IDs: I bluntly store the conn in struct lu_operation and re-use it later. For synchronous responses (i.e. no asynchronous activity in between) this will work. So I think it's an optimization for those cases, and we shouldn't rely on this to always work for all transactions at all time in the future. Rather, we should make sure it works even without that optimization? -- - Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 6 Date: Fri, 24 Feb 2017 17:12:02 +0100 From: Keith <keith at rhizomatica.org<mailto:keith at rhizomatica.org>> To: Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>> Cc: OpenBSC Mailing List <openbsc at lists.osmocom.org<mailto:openbsc at lists.osmocom.org>> Subject: Re: Handover and load balancing on SysmoBTS 2050 Message-ID: <ca4d6dc2-fa43-8eaa-8c39-821939d87e52 at rhizomatica.org<mailto:ca4d6dc2-fa43-8eaa-8c39-821939d87e52 at rhizomatica.org>> Content-Type: text/plain; charset=windows-1252 On 21/02/2017 16:14, Harald Welte wrote: Just a quick response: jolly implemented "traffic handover" aka "load balancing" 3 years ago as part of a branch (I believe for a customer), but unfortunately this never was merged back to master. Reading the commit log, this looks terrific... Meanwhile, we already have all the code for execution of hand-overs in place. We also have dynamic timeslots in place. So the "mechanics" should all be there to add the two missing features from those old branches: a) de-fragmenting of channels (i.e. merging two separate TCH/H into one timeslot, so the other timeslot can be switched to TCH/F or PDCH on demand b) load/traffic based hand-over So essentially everything I was talking about is already implemented! My question then would be, and I understand maybe the answer is not so easily available without a full code review, but Was it unfortunately never merged back to master because Simply no one ever made the effort to do so. OR There were problems with the code, disagreement on the implementation or incompatibilities with other developments etc.. If it's the former, I'll have a go at this. If it is the latter, it's probably beyond my skills. The general strategy I would normally assume is to * switch to half-rate channels with AMR whenever possible * use dynamic channel switching to switch between TCH/H (default) and TCH/F (if neded) Absolutely, I must revisit this one. It was shelved for us due to my understanding a few months ago that if we implemented AMR, then we couldn't also use FR. As that's all now resolved, I can implement, test and report. :-) ------------------------------ Subject: Digest Footer _______________________________________________ OpenBSC mailing list OpenBSC at lists.osmocom.org<mailto:OpenBSC at lists.osmocom.org> https://lists.osmocom.org/mailman/listinfo/openbsc ------------------------------ End of OpenBSC Digest, Vol 28, Issue 20 *************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170225/6bb2580d/attachment.htm>