OpenBSC August 2018

openbsc@lists.osmocom.org

11 participants
11 discussions

by Martin Nagy

Hi all, After buying a super Sim Kit (16 in 1) from China, I tried the reader (green PCB inside a blue transparent plastic case with a blue LED) and SIM (identified as a fakesupersim) with pysim tool. However i am getting the following error: /pySim-prog.py -n 26C3 -c 49 -x 262 -y 42 -z 1234 -j 1 -t auto Insert card now (or CTRL-C to cancel) Autodetected card type fakemagicsim Generated card parameters : > Name : 26C3 > SMSP : e1ffffffffffffffffffffffff058100945555ffffffffffff000000 > ICCID : 8949262427518313026 > MCC/MNC : 262/42 > IMSI : 262422461512085 > Ki : 7b74741a1ee14337ec23f9ab92a13648 > OPC : ccd867d60797d8d45354a51b3ef568ff Programming ... Traceback (most recent call last): File "./pySim-prog.py", line 530, in <module> card.program(cp) File "/home/nadicek/pysim/pysim/pySim/cards.py", line 231, in program self._scc.update_binary('6f30', hplmn + 'ff' * (tl-3)) File "/home/nadicek/pysim/pysim/pySim/commands.py", line 53, in update_binary return self._tp.send_apdu_checksw(pdu) File "/home/nadicek/pysim/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1])) RuntimeError: SW match failed ! Expected 9000 and got 9804. I checked mailing lists and haven’t found anybody who had similar problem with pysim. Also I have tried forcing different models of SIM, but nothing is working. Obviously I can remove this check from the script file (__init__.py in /pySim/transport), however somebody had a reason to put such condition there. I would like to ask if it is safe to remove that line of code and the purpose of that line of code. Thanks a lot and best regards Martin

1 week, 6 days

Re: Help with sccp library

by mosbah abdelkader

> I don't understand. This callback will be called with data you need to write > to the network. In case of MTP Level3 you will need to wrap that around the > msgb you got. I means: is the interaction with mtp3 layer implemented (is sending sccp data by mtp3 implemented by the library?)? Also, what about the reception of data from mtp3 layer. is that implemented in the sccp lib. I am asking these questions because I see the code of mtp3 in the lib but no significant call is present in the sccp part of the lib. Thank you for your help.

1 month, 3 weeks

dynamic traffic channels

by Neels Hofmeyr

On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote: > [translated from german] > is it certain that we switch a channel to PDCH only when > gprs mode != none? A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we send a PDCH ACT message. We send a PDCH ACT message - during init (CHANNEL OML's state changed to enabled -> send PDCH ACT), - and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH. So the question is, when we receive a channel release ack, could that be the PDCH release and we switch PDCH right back on by accident? No, because we only receive a chan rel ack when the *TCH/F* is being released. That is because the PDCH release is initiated "internally" from the PDCH DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches on, which existed before dyn PDCH: if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) { LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n", gsm_lchan_name(lchan)); return 0; } In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but not in the rsl_rx_dyn_pdch(). This is analogous to the ip.access way -- the ip.access nanobts replies to a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel release ack. Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH for clarity? (But we shouldn't actually send a release ack, to stay compatible.) Even though it works as-is, we should indeed add another flag check: - We do check the flags that no ACT/DEACT is already pending; - And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE; - But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE. This should never happen, but it would make sense to ensure that. ~Neels

3 months, 1 week

Save the Date: OsmoCon 2018 on October 18-19, 2018

by Harald Welte

== OsmoCon 2018 == OsmoCon (Osmocom Conference) 2018 is the technical conference for Osmocom users, operators and developers! We are happy to announce the date of OsmoCon 2018. It has been scheduled on October 18 + 19, 2018 and will happen in Berlin, Germany. For the second time, the Osmocom Conference brings together users, operators and developers of the Osmocom Open Source cellular infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN and others. Join us for two days of presentations and discussions with the main developers behind Open Source Mobile Communications, as well as commercial and non-profit users of the Osmocom cellular infrastructure software. You can find some initial information in our wiki at http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018 which will be updated as more information becomes available. == Call for Participation == We're also at the same time announcing the Call for Participation and call on everyone with experiences to share around the Osmocom member projects to submit talks, workshops, discussions or other proposals. You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp We are particularly looking for contributions about: * updates on features/functionality/status of individual Osmocom projects * success stories on how Osmocom projects are deployed in practice * migration from OsmoNITB to the post-NITB architecture * tutorials / workshops on how to setup / analyze Osmocom projects * statistics, reporting, operations aspects of Osmocom projects * third-party open source utilities to be used with Osmocom projects Looking forward to meeting many existing and new Osmocom users at OsmCon this October! Regards, Harald Welte -- - 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)

6 years, 10 months

The magic behaviour of 'logging level all LEVEL'

by Vadim Yanitskiy

Hi all, A discussion was started during the review of https://gerrit.osmocom.org/10116/. The main idea of this change is to fix the behaviour of 'logging level all LEVEL', but I think it was also mixed with some additional feature, which I would like to discuss here, publicly. First of all, the change introduces a new special logging level 'unset', which allows one to reset a given category (i.e. unset its custom value): !! Initial logging configuration: logging level all error logging level mncc debug logging level pag notice logging level meas debug !! Resetting DMNCC: # logging level mncc unset !! So, now DMNCC has no custom log level, it will use !! the default level (in this example it is 'error'): logging level all error logging level pag notice logging level meas debug This feature looks fine and extremely useful for me. But (among fixing) this change additionally changes the behaviour of a command for setting the default logging category (i.e. 'logging level all LEVEL'): !! Initial logging configuration: logging level all error logging level mncc debug logging level pag notice logging level meas debug !! Changing the default logging level: # logging level all debug !! Ahhh, I've lost my custom levels :( logging level all debug !! What I expected to get: logging level all debug logging level mncc debug logging level pag notice logging level meas debug So, together with changing the default logging category, this command now would also reset all custom settings... I am not sure this is exactly what one need/expect, so I would like to share the following ideas: 1) The category 'all' looks/sounds confusing when it's used in such cases like this: # logging level all debug because one can interpret it like: "set all categories to debug". despite actually (according to the implementation) this is related to the default logging policy. Maybe, we should rename it to 'default'? So, 'logging level all LEVEL' would *set all categories* to a given logging LEVEL, while 'logging level default LEVEL' would only affect the default logging level... 2) Introducing the new command: # logging level unset LEVEL which is intended to assign a given LEVEL to all categories, which have no custom logging level (i.e. have 'unset'), would make the idea of having default logging policy meaningless. Setting logging level(s) for all possible categories (using this command), looks like writing iptables rules for all possible and impossible cases instead of using the DEFAULT policy... 3) The introduced behaviour of resetting all categories to 'unset' could be implemented in a separate function, and can be represented by a separate command: # logging level unset-all The name of this command clearly defines the expected behaviour. Moreover, it doesn't affect the default logging level, which can be still changed by a separate command. As we (me and Pau) have different opinions, or we simply don't understand each other, let's make this discussion public, and let's see what others think about this... With best regards, Vadim Yanitskiy.

6 years, 12 months

GGSN p-t-p address?

by Keith

Hi all, idle curiosity here more than anything..... I noticed that if I bring up a pppd link with a GSM modem to an osmo stack GPRS network, I get assigned an IP address from the pool as configured on osmo-ggsn; ip prefix dynamic 10.20.0.0/16 ip dns 0 192.168.11.2 ip dns 1 192.168.11.2 ip ifconfig 10.20.20.253/16 but the p-t-p address is 192.168.100.101; Sat Aug 18 15:45:38 2018 daemon.notice pppd[21227]: local IP address 10.20.0.8 Sat Aug 18 15:45:38 2018 daemon.notice pppd[21227]: remote IP address 192.168.100.101 Here's the resulting ifconfig: 3g-gwan Link encap:Point-to-Point Protocol inet addr:10.20.0.8 P-t-P:192.168.100.101 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:3 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:54 (54.0 B) TX bytes:76 (76.0 B) This is not really a problem but I thought it was weird so I looked for this IP (192.168.100.101) in the source code but it was nowhere to be found. I'm a bit rusty on ppp, but should it not be the address configured in the ggsn's ip config? I thought maybe it was coming from the local pppd stack, so I booted an old windows 7 machine and connnected the GSM modem, and it got the same p-t-p address of 192.168.100.101 thnx/ K.

7 years

CSN.1 directory

by benoit michau

Dear osmocom community, This email to point to a recent development I made on CSN.1, which might be of interest to some of you. I extracted and consolidated all CSN.1 definitions from 24.008, 44.018 and 44.060 (the "consolidation" part was quite hard...). I have also developped a CSN.1 to Python translater, and a runtime to encode / decode any CSN.1 structures. This is available here: https://github.com/ANSSI-FR/pycrate/tree/master/pycrate_csn1dir and there: https://github.com/ANSSI-FR/pycrate/tree/master/pycrate_csn1 And there are some quick explanations on how to use this in the wiki: https://github.com/ANSSI-FR/pycrate/wiki/Using-the-pycrate-csn1-translator-… Regards Benoit

7 years

Move osmo-bsc (with osmo-bts-trx and osmo-trx-lms) to another device

by Norbertas Kremeris

Dear all, I have a running and working osmocom network stack (2g only, no GPRS/DATA) with osmo-trx-lms using a LimeSDR mini (osmo-trx-lms, osmo-bts-trx, osmo-bsc, osmo-hlr, osmo-stp, osmo-msc, a and single osmo-mgw process) , and I would like to have osmo-bts-trx, osmo-trx-lms and osmo-bsc moved to another computer. I would like to have an AoIP connection between the pc1 and pc2. As far as i understand, osmo-bsc and osmo-mgw communicate over AoIP (as per the manual here http://ftp.osmocom.org/docs/latest/osmomgw-usermanual.pdf). My knowledge about the interconnection of all the osmocom core components is rather limited, and what at first seemed like a trivial task (to move osmo-bsc to the other computer and changing the msc mgw remote ip) has turned into a 2 day ordeal with me trying to wrap my head around the functionality of all the core components without any success. I have modified my stack to work with a single osmo-mgw process (but the moving of osmo-bsc does not work with osmo-mgw-for-bsc and osmo-mgw-for-msc either). Attached are all the configuration files used. The IP of the osmo-bts-trx, osmo-trx-lms and osmo-bsc running pc (PC1) is 192.168.1.249, the ip of the pc (PC2) that is running the core network components is 192.168.1.219. All my osmocom components are built from source (latest tags). Running the osmoBSC on the PC1 connects to osmo-bts successfully and does result in a network being shown on the phone, but osmo-bsc constantly throws errors: <0007> a_reset.c:106 A-RESET(msc-0)[0x1ee0530]{DISC}: (re)sending BSSMAP RESET message... <0007> osmo_bsc_sigtran.c:92 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP <001c> m3ua.c:507 XUA_AS(as-clnt-msc-0)[0x1edfd30]{AS_DOWN}: Event AS-TRANSFER.req not permitted Any pointers would be very appreciated. Sincerely, Norbertas

7 years

SDCCH not released if Radio Link Failure / Sending Connection Failure: cause = 0x001 Experienced in osmo-bsc and osmo-bts-trx

by Ron

Hi Community, We had encountered an issue regarding the SDCCH channel not being released immediately after a "Radio Link Failure" is detected in osmo-bsc and an equivalent error of "Sending Connection Failure: cause = 0x01" in osmo-bts-trx. Error in osmo-bts-trx: <0000> rsl.c:797 (bts=0,trx=0,ts=0,ss=0) Sending Connection Failure: cause = 0x01 Error in osmo-bsc: <0003> abis_rsl.c:1372 (bts=0,trx=0,ts=0,ss=0) CONNECTION FAIL in state ACTIVE CAUSE=0x01(Radio Link Failure) With this issue, the SDCCH channel will then be exhausted and no other subscriber can attach and do any services (call and SMS). As per advised by Neels, we tried to used the neels/inter_bsc_ho branch for osmo-bsc to test if this issue is fixed. We are happy to inform the community that the SDCCH channel issue we had is not experienced from the neels/inter_bsc_ho branch but a different bug was experienced. The bug we seen in this branch is that, even we have a 2 TRX configuration in our setup, the osmo-bsc only uses the first TRX configuration. Kindly see logs below for your reference. OSMO-BSC: # /usr/local/osmo-bsc/src/osmo-bsc/osmo-bsc -c /root/demo/osmo-bsc.cfg logging level cc (everything|debug|info|notice|error|fatal) logging level mgcp (everything|debug|info|notice|error|fatal) <001f> osmo_ss7.c:1270 0: ASP Restart for server not implemented yet! [0;m% Ignoring deprecated logging level everything <0013> telnet_interface.c:104 telnet at 127.0.0.1 4242 [0;m<0015> input/ipaccess.c:846 enabling ipaccess BSC mode on 0.0.0.0 with OML 3002 and RSL 3003 TCP ports [0;m<001a> control_if.c:887 CTRL at 127.0.0.1 4249 [0;m<0007> osmo_bsc_sigtran.c:466 Initializing SCCP connection to MSC msc-0 [0;m<0007> osmo_bsc_sigtran.c:476 CS7 Instance identifier, A-Interface: 0 [0;m<0020> sccp_user.c:397 msc-0: Using SS7 instance 0, pc:0.23.3 [0;m<0020> sccp_user.c:421 msc-0: Using AS instance MSC_Test [0;m<0020> sccp_user.c:426 msc-0: Creating default route [0;m<0020> sccp_user.c:481 msc-0: Using ASP instance Huawei_MSC_Test [0;m<0020> sccp_user.c:484 msc-0: Creating SCCP instance [0;m<0007> osmo_bsc_sigtran.c:519 (msc-0) A-interface: local (BSC) SCCP address: RI=SSN_PC,PC=0.23.3,SSN=BSSAP [0;m<0007> osmo_bsc_sigtran.c:521 (msc-0) A-interface: remote (MSC) SCCP address: RI=SSN_PC,PC=0.23.1,SSN=BSSAP [0;m<0007> a_reset.c:106 A-RESET(msc-0)[0xce7480]{DISC}: (re)sending BSSMAP RESET message... [0;m<0007> osmo_bsc_sigtran.c:92 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP [0;m<001f> m3ua.c:507 XUA_AS(MSC_Test)[0xcdb9d0]{AS_DOWN}: Event AS-TRANSFER.req not permitted [0;m<0007> a_reset.c:106 A-RESET(msc-0)[0xce7480]{DISC}: (re)sending BSSMAP RESET message... [0;m<0007> osmo_bsc_sigtran.c:92 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP [0;m<001f> m3ua.c:507 XUA_AS(MSC_Test)[0xcdb9d0]{AS_DOWN}: Event AS-TRANSFER.req not permitted [0;m<0007> a_reset.c:106 A-RESET(msc-0)[0xce7480]{DISC}: (re)sending BSSMAP RESET message... [0;m<0007> osmo_bsc_sigtran.c:92 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP [0;m<001f> m3ua.c:507 XUA_AS(MSC_Test)[0xcdb9d0]{AS_INACTIVE}: Event AS-TRANSFER.req not permitted [0;m<0022> m3ua.c:634 asp-Huawei_MSC_Test: Received NOTIFY Type State Change:AS Inactive () [0;m<001f> xua_default_lm_fsm.c:353 xua_default_lm(Huawei_MSC_Test)[0xce6de0]{ACTIVE}: Ignoring primitive M-ASP_ACTIVE.confirm [0;m<0022> m3ua.c:634 asp-Huawei_MSC_Test: Received NOTIFY Type State Change:AS Active () [0;m<0007> a_reset.c:106 A-RESET(msc-0)[0xce7480]{DISC}: (re)sending BSSMAP RESET message... [0;m<0007> osmo_bsc_sigtran.c:92 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP [0;m<0007> osmo_bsc_bssap.c:58 RESET ACK from MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP [0;m<0007> a_reset.c:74 A-RESET(msc-0)[0xce7480]{DISC}: SIGTRAN connection succeded. [0;m<0015> input/ipa.c:265 accept()ed new link from 192.168.1.170 to port 3002 [0;m[1;36m<0004> abis_nm.c:499 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix. [0;m[1;36m<0004> abis_nm.c:499 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix. [0;m[1;36m<0004> abis_nm.c:499 BTS0 feature 'Fullrate speech V1' reported via OML does not match statically set feature: 1 != 0. Please fix. [0;m[1;36m<0004> abis_nm.c:499 BTS0 feature 'Halfrate speech V1' reported via OML does not match statically set feature: 1 != 0. Please fix. [0;m[1;36m<0004> abis_nm.c:499 BTS0 feature 'Fullrate speech EFR' reported via OML does not match statically set feature: 1 != 0. Please fix. [0;m[1;36m<0004> abis_nm.c:499 BTS0 feature 'Fullrate speech AMR' reported via OML does not match statically set feature: 1 != 0. Please fix. [0;m[1;36m<0004> abis_nm.c:499 BTS0 feature 'Halfrate speech AMR' reported via OML does not match statically set feature: 1 != 0. Please fix. [0;m[1;36m<0004> abis_nm.c:566 OC=BTS(01) INST=(00,ff,ff): BTS0: ARI reported sw[0/2]: osmobts is 0.8.1.35-6575f0 [0;m[1;36m<0004> abis_nm.c:438 BTS0 reported variant: omso-bts-trx [0;m[1;36m<0004> abis_nm.c:460 BTS0 Attribute Manufacturer Dependent State is unreported [0;m[1;36m<0004> abis_nm.c:566 OC=BTS(01) INST=(00,ff,ff): BTS0: ARI reported sw[0/1]: TRX_PHY_VERSION is Unknown [0;m[1;36m<0004> abis_nm.c:460 BTS0 Attribute Manufacturer Dependent State is unreported [0;m[1;36m<0004> abis_nm.c:566 OC=BTS(01) INST=(00,ff,ff): BTS0: ARI reported sw[0/1]: TRX_PHY_VERSION is Unknown [0;m[1;36m<0004> abis_nm.c:2827 IPA RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00 [0;m[1;36m<0004> abis_nm.c:2827 IPA RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00 [0;m<0015> input/ipa.c:265 accept()ed new link from 192.168.1.170 to port 3003 [0;m[1;35m<0003> osmo_bsc_main.c:282 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 111 using MCC-MNC 101-01 LAC=20259 CID=6966 BSIC=63 [0;m<0015> input/ipa.c:265 accept()ed new link from 192.168.1.170 to port 3003 [0;m[1;35m<0003> osmo_bsc_main.c:282 bootstrapping RSL for BTS/TRX (0/1) on ARFCN 13 using MCC-MNC 101-01 LAC=20259 CID=6966 BSIC=63 [0;m[1;31m<0011> bts_ipaccess_nanobts.c:314 timeslot(0-0-0-CCCH_SDCCH4)[0xce0220]{UNUSED}: Event TS_EV_OML_READY not permitted [0;m[1;31m<0011> bts_ipaccess_nanobts.c:314 timeslot(0-0-1-SDCCH8)[0xce0650]{UNUSED}: Event TS_EV_OML_READY not permitted [0;m[1;31m<0011> bts_ipaccess_nanobts.c:314 timeslot(0-0-2-TCH_F)[0xce0c00]{UNUSED}: Event TS_EV_OML_READY not permitted [0;m[1;31m<0011> bts_ipaccess_nanobts.c:314 timeslot(0-0-3-TCH_F)[0xce11b0]{UNUSED}: Event TS_EV_OML_READY not permitted [0;m[1;31m<0011> bts_ipaccess_nanobts.c:314 timeslot(0-0-4-TCH_F)[0xce1760]{UNUSED}: Event TS_EV_OML_READY not permitted [0;m[1;31m<0011> bts_ipaccess_nanobts.c:314 timeslot(0-0-5-TCH_F)[0xce1d10]{UNUSED}: Event TS_EV_OML_READY not permitted [0;m[1;31m<0011> bts_ipaccess_nanobts.c:314 timeslot(0-0-6-TCH_F)[0xce22c0]{UNUSED}: Event TS_EV_OML_READY not permitted [0;m[1;31m<0011> bts_ipaccess_nanobts.c:314 timeslot(0-0-7-TCH_F)[0xce2870]{UNUSED}: Event TS_EV_OML_READY not permitted [0;m [1;35m<0003> abis_rsl.c:1364 (bts=0) CHAN RQD: reason: other (ra=0xfe, neci=0x00, chreq_reason=0x04) [0;m[1;32m<0010> lchan_fsm.c:76 lchan(0-0-0-CCCH_SDCCH4-0)[0xce7f70]{WAIT_RLL_RTP_ESTABLISH}: (type=SDCCH) lchan allocation failed in state WAIT_RLL_RTP_ESTABLISH: Timeout [0;m[1;32m<0010> lchan_fsm.c:95 lchan(0-0-0-CCCH_SDCCH4-0)[0xce7f70]{WAIT_RLL_RTP_ESTABLISH}: (type=SDCCH) Tx Immediate Assignment Reject (lchan allocation failed in state WAIT_RLL_RTP_ESTABLISH: Timeout) [0;m[1;35m<0003> abis_rsl.c:1364 (bts=0) CHAN RQD: reason: Location updating (ra=0x09, neci=0x00, chreq_reason=0x03) [0;m<0007> fsm.c:299 SUBSCR_CONN[0xce7910]{INIT}: Allocated [0;m<000f> fsm.c:299 LCLS[0xce7a40]{NO_LCLS}: Allocated [0;m<000f> fsm.c:329 LCLS[0xce7a40]{NO_LCLS}: is child of SUBSCR_CONN[0xce7910] OSMO-BSC CLI: OsmoBSC# show network BSC is on MCC-MNC 101-01 and has 1 BTS Encryption: A5/0 NECI (TCH/H): 0 Use TCH for Paging any: 0 Handover: Off Current Channel Load: CCCH+SDCCH4: 25% (1/4) TCH/F: 0% (0/6) SDCCH8: 0% (0/8) Last RF Command: Last RF Lock Command: OsmoBSC# show run Current configuration: ! ! bts 0 type sysmobts band GSM900 cell_identity 6966 location_area_code 20259 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 radio-link-timeout 32 channel allocator ascending rach tx integer 9 rach max transmission 7 channel-descrption attach 1 channel-descrption bs-pa-mfrms 5 channel-descrption bs-ag-blks-res 1 no access-control-class-ramping access-control-class-ramping-step-interval dynamic access-control-class-ramping-step-size 1 early-classmark-sending forbidden early-classmark-sending-3g allowed ip.access unit_id 1800 0 oml ip.access stream_id 255 line 0 neighbor-list mode manual-si5 neighbor-list add arfcn 100 neighbor-list add arfcn 200 si5 neighbor-list add arfcn 10 si5 neighbor-list add arfcn 20 codec-support fr hr efr amr gprs mode none no force-combined-si trx 0 rf_locked 0 arfcn 111 nominal power 23 max_power_red 20 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config SDCCH8 hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 timeslot 6 phys_chan_config TCH/F hopping enabled 0 timeslot 7 phys_chan_config SDCCH8+CBCH hopping enabled 0 trx 1 rf_locked 0 arfcn 13 nominal power 23 max_power_red 20 rsl e1 tei 0 timeslot 0 phys_chan_config TCH/F hopping enabled 0 timeslot 1 phys_chan_config TCH/F hopping enabled 0 timeslot 2 phys_chan_config TCH/F hopping enabled 0 timeslot 3 phys_chan_config TCH/F hopping enabled 0 timeslot 4 phys_chan_config TCH/F hopping enabled 0 timeslot 5 phys_chan_config TCH/F hopping enabled 0 timeslot 6 phys_chan_config TCH/F hopping enabled 0 timeslot 7 phys_chan_config TCH/F hopping enabled 0 OSMO-BTS-TRX CLI: OsmoBTS# show run Current configuration: ! ! line vty no login ! e1_input e1_line 0 driver ipa e1_line 0 port 0 no e1_line 0 keepalive phy 0 osmotrx ip local 127.0.0.1 osmotrx ip remote 127.0.0.1 no osmotrx ms-power-loop osmotrx timing-advance-loop osmotrx base-port local 5800 osmotrx base-port remote 5700 osmotrx fn-advance 5 osmotrx rts-advance 5 instance 0 osmotrx rx-gain 0 osmotrx tx-attenuation 7 instance 1 osmotrx rx-gain 0 osmotrx tx-attenuation 7 bts 0 band GSM900 ipa unit-id 1800 0 oml remote-ip 5.40.0.1 rtp jitter-buffer 100 rtp port-range 16384 17407 paging queue-size 200 paging lifetime 0 uplink-power-target -75 gsmtap-sapi ccch gsmtap-sapi pdtch min-qual-rach 50 min-qual-norm -5 max-ber10k-rach 1707 trx 0 power-ramp max-initial 0 mdBm power-ramp step-size 2000 mdB power-ramp step-interval 1 ms-power-control dsp phy 0 instance 0 trx 1 power-ramp max-initial 0 mdBm power-ramp step-size 2000 mdB power-ramp step-interval 1 ms-power-control dsp phy 0 instance 1 end OSMO-TRX CLI: OsmoTRX# show run Current configuration: ! ! stats interval 5 ! line vty no login ! trx bind-ip 127.0.0.1 remote-ip 127.0.0.1 multi-arfcn disable swap-channels disable egprs disable chan 0 chan 1 end Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

7 years

OsmoCon 2018 draft schedule announced

by Harald Welte

Dear Osmocom community, the first schedule of the 2018 incarnation of OsmoCon 2018 has been announced, see http://osmocom.org/news/99 for the announcment and https://pretalx.sysmocom.de/osmocon2018/schedule/ for the actual schedule. At OsmoCon, we are not targetting developers, but more the wider community and Osmocom users. It would be great to meet many of you and hear more about your relation to Osmocom. Tickets are available from https://pretix.sysmocom.de/sysmocom/osmocon2018/, and until August 31st the early bird discount still applies. For those with a community / "just for fun" background and no employer that would cover the ticket, we have a number of subsidized community discount vouchers available. See the OsmoCon 2018 wiki page at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018 for more information. Looking forward to meeting as many of you as possible in roughly two months from now, Harald Welte -- - 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)

7 years

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC August 2018