Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092019-09-12T14:07:31ZOpen Source Mobile Communications
Redmine OsmoMSC - Feature #4200 (In Progress): Work around nano3G-S16 requiring RAB ID to be below 16https://osmocom.org/issues/42002019-09-12T14:07:31Zefistokl
<p>Hardware: ip.access nano3g S16.</p>
<p>Tested against osmo-msc version branches 35c3 and cccamp19 (with Message Class and RAT GSUP IEs stripped out). Reproduced 3 times.</p>
<p>In the trace there are 17 incoming SIP calls. The last 2 failed (around packet 36826 and 37625). In the RAB-AssignmentResponse's for them I see "radioNetwork: failure-in-the-radio-interface-procedure (14)".</p>
<p>If I restart the osmo-msc, I can make another 15 calls.</p>
<p>IPs:<br />10.0.2.247 - nano3g S16<br />10.0.2.244 - RNC:<br /> - 10.0.2.244:5060 osmo-sip-connector<br /> - 10.0.2.244:5064 local PBX (kamailio)<br />172.48.2.1 - Remote PBX (kamailio)<br />172.48.1.5 - GSUP server</p>
<p>Note:<br />Apart from the osmocom software there is Kamailio and rtpengine installed alongside osmo-sip-connector to allow for transcoding. I've set it in a way so that it "sleeps" for 3 seconds before passing SIP INVITE to osmo-sip-connector. (If I don't do this then the UE will not respond to Paging Request (assuming it doesn't have enough time after Iu-Release which happens after USSD))</p> OsmoSGSN - Bug #3940 (New): TTCN-3: Iu: test UMTS Authhttps://osmocom.org/issues/39402019-04-18T14:21:20Zlynxis
<p>Test UMTS Auth on the Iu Interface via TTCN-3</p> OsmoSGSN - Support #3920 (In Progress): PCAPs files of 3G PS for Osmocom network and Commercial onehttps://osmocom.org/issues/39202019-04-12T12:51:19Zefistokl
<p>In iphone-6s-q.pcap - commercial software, trace taken on 10.0.2.195:<br />(around between 10:22:44 and 10:23:17 I didn't have internet, maybe temporary fail of the system to respond to the packet 10754. All other time the data was working)<br />10.0.2.199 - nano3g ip.access S8<br />10.0.2.195 - (not osmocom) core network (without HLR and GGSN)<br />10.0.1.123 or 192.168.14.16 (same host) - GGSN and HLR</p>
<p>In iphone-6s-osmocom.pcap - osmocom based system. Data stopped working around 10:05:59 (time in the trace, or packet 3727), trace taken on 10.0.2.51:<br />10.0.2.52 - nano3g ip.access S8<br />10.0.2.51 - osmocom host (without HLR and GGSN)<br />10.0.1.123 or 192.168.14.16 (same host) - GGSN<br />172.48.1.5 - HLR</p>
<p>At first glance it seems that Osmo-SGSN doesn't respond properly to (GMM) Service Requests which come some time after initial PS activation. I haven't inspected the traces thoroughly yet.</p> OsmoGSMTester - Feature #2861 (New): osmo-gsm-tester: Add 3g support for sysmocell-5khttps://osmocom.org/issues/28612018-01-22T14:55:21Zpespin
<p>Probably nothing different than the implementation required for nano3g is needed, only setting up the sysmocell5k and creating a type to set it up as 3g.</p> OsmoGSMTester - Feature #2860 (New): osmo-gsm-tester: Add 3g support with nano3G boardhttps://osmocom.org/issues/28602018-01-22T14:50:17ZpespinOsmoHLR - Feature #2840 (New): HLR should allow 2g-only or 3g-only subscribershttps://osmocom.org/issues/28402018-01-18T20:34:12Zlaforge
<p>right now, any subscriber known to the HLR can use both 2G and 3G services. It would be useful to restrict this to either one of the two technologies for each subscriber individually, similar to the nam_cs / nam_ps that we already have.</p> Cellular Network Infrastructure - Bug #2839 (New): statistics split betwteen 2G and 3Ghttps://osmocom.org/issues/28392018-01-18T20:05:59Zlaforge
<p>many of our statistics/countrs currnetly don't distinguish between 2G and 3G bearer. This means we cannot know how many 2G vs 3G LU we have received in a given period of time, for example.</p> OsmoSGSN - Bug #1818 (New): IuPS: CN should Iu Release in certain situationshttps://osmocom.org/issues/18182016-10-12T02:10:57Zneelsnhofmeyr@sysmocom.de
<p>I observe sporadic data service failure which is solved by reconnecting the UE.</p>
<p>The situation looks like this:</p>
<p>The UE keeps sending GMM Attach Requests and the SGSN keeps answering with GMM Attach<br />Accepts (more often than it receives Attach Requests even), but the process never<br />goes on after that. I notice the lack of Iu Releases.</p>
<p>When I put the phone in flight mode and back online, an Iu Release (and complete UE DE-REGISTER)<br />is done, and after that 3G data service works immediately and well.</p>
<p>The SGSN never sends and Iu Release on own accord nor invalidates the UE conn unless the<br />UE asks for an Iu Release.</p>
<p>There should be timeouts and the SGSN should do an Iu Release on a given conn at some<br />point. The UE will then re-connect with another InitialUE message and hopefully fix things.</p>
<p>There is possibly another hidden root cause for this situation, but this issue calls<br />for sane Iu Release timeouts by the SGSN.</p>