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