OpenBSC January 2022

openbsc@lists.osmocom.org

7 participants
56 discussions

OsmoDevCall on Jan 14, 2022: Codecs in OsmoMSC, MNCC and SIP
by Harald Welte 12 Jan '22

12 Jan '22

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall on January 14, 2022 at 20:00 CET at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation "Codesc in OsmoMSC, MNCC and SIP" by neels 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Refreshing/Resetting UICC (SysmoISIM-SJA2)
by bryan coxwell 06 Jan '22

06 Jan '22

Hi all, I have a SysmoISIM-SJA2 which I believe doesn't have a CAT application and doesn't support the SUSPEND APDU (per the manual). Given that, is there any way to reset/refresh the card through APDU commands (or through any other means)? Would something along the lines of deactivating and then reactivating the USIM application work? Thanks, Bryan

2 4

lists.osmocom.org migrated to mailman3
by Harald Welte 04 Jan '22

04 Jan '22

Dear Osmocom community, today our mailing list server lists.osmocom.org has finally been migrated from mailman2-on-freebsd to mailman3-on-linux. This also included a variety of changes to DNS. I'll spare you the details, but everything _should_ be up and running now. * The List-Id headers should not have changed. * all list subscriptions + user accounts have been converted. * old 'static html' archives are still available (read only) at URLs like https://lists.osmocom.org/pipermail/baseband-devel/ * old List URLs like https://lists.osmocom.org/mailman/listinfo/baseband-devel are redirected to their respective modern counterparts In case you notice any mailing list related problem, please don't hesitate to contact me. Happy hacking, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

None
by None 03 Jan '22

03 Jan '22

those harmonics) must be above: -30 dBm @ 30 kHz span above 1 GHz -36 dBm @ 30 kHz span below 1 GHz In case of UmTRX without an amplifier it's enough to use a ceramic or SAW duplexer to bring harmonics below those levels. For those buying UmTRX's as a lab package of universal UmDESKs, we offer to buy an external ceramic duplexers. These improves coverage and solves the out of band noise issues. For those buying band-specific UmDESK's, we use SAW duplexers, which are even more efficient in reducing out of band noise. >> A calibrated USRP N200 running osmo-trx passes RF spectrum and >> modulation accuracy requirements of 3GPP 05.05 by very large margins >> and is competitive with commercial GSM equipment in this regard. Other >> SDR devices are also capable to varying degrees. > > The policy of FCC vs. European Union is quite different. There are more > norms that apply in Europe. You're obviously more proficient in European norms. Could you point me to a link where we could find these differences between the ETSI published GSM Standard and European harmonized norms? It would be a very good addition to the OpenBSC wiki's "Standards" page. --=20 Regards, Alexander Chemeris. CEO, Fairwaves LLC / =D0=9E=D0=9E=D0=9E =D0=A3=D0=BC=D0=A0=D0=B0=D0=B4=D0= =B8=D0=BE http://fairwaves.ru

1 0

None
by None 03 Jan '22

03 Jan '22

cell into=20 operation, but during normal operation?! > -- > Regards, > Alexander Chemeris. > CEO, Fairwaves LLC / =D0=9E=D0=9E=D0=9E = =D0=A3=D0=BC=D0=A0=D0=B0=D0=B4=D0=B8=D0=BE > http://fairwaves.ru Ralph.

1 0

None
by None 03 Jan '22

03 Jan '22

> Anyway, I thought that the GPRS support is part of the OpenBTS > development, and any hardware that can run OpenBTS is also capable of > doing GPRS, but it is clear, that there are differences in the level > of support, even between SDR like devices. The majority of the code of osmo-pcu has been contributed by or on behalf of sysmocom. If you take a look at the development of the PCU for the last 6 months you will clearly see that sysmocom is doing all the work. Just like with OpenBSC a lot of others benefit from our work though. ;) > I still think that it would be nice, to clarify all this packet data > related stuff on the site.

1 0

None
by None 03 Jan '22

03 Jan '22

* When an external protocol changes, the version number needs to change. I added MNCC protocol versioning as OpenBSC and LCR were out of sync and then funny things happened. This one line change of the version number can save you hours in debugging! * When a new feature is added, ask for a testcase. E.g. specially the E1 bit fiddling as it is so rarely used that it is likely to bitrot. * Check the error paths. Developers tend to only test with a single phone, not run into error paths, not force them to be taken during development (faul injection). * For things like device work-arounds ask if they are really necessary, e.g. I have my doubts for the RTP timestamp handling. * General code hygiene. Don't have the action take place four tabs in in a thousand line code method, don't use magic numbers, don't repeat yourself etc. Code is read a lot more than it is written. Besides smaller methods being easier to write unit tests for, they are easier to understand/review. I have merged two patches from this patchset but they required multiple rounds and my spare time is really limited. cheers holger

1 0

None
by None 03 Jan '22

03 Jan '22

it should return gsm_phys_chan_config? In the implementation we do have: static const enum abis_nm_chan_comb chcomb4pchan[] = { and at the indexes we use values from gsm_phys_chan_config. Do you think the below is correct? holger diff --git a/include/osmocom/gsm/abis_nm.h b/include/osmocom/gsm/abis_nm.h index 4dee012..4682ead 100644 --- a/include/osmocom/gsm/abis_nm.h +++ b/include/osmocom/gsm/abis_nm.h @@ -43,7 +43,7 @@ const char *abis_nm_test_name(uint8_t test); int abis_nm_chcomb4pchan(enum gsm_phys_chan_config pchan); -enum abis_nm_chan_comb abis_nm_pchan4chcomb(uint8_t chcomb); +enum gsm_phys_chan_config abis_nm_pchan4chcomb(uint8_t chcomb); /*! @} */ diff --git a/src/gsm/abis_nm.c b/src/gsm/abis_nm.c index bb7008b..2c8f871 100644 --- a/src/gsm/abis_nm.c +++ b/src/gsm/abis_nm.c @@ -407,7 +407,7 @@ const struct value_string abis_nm_adm_state_names[] = { { 0, NULL } }; -static const enum abis_nm_chan_comb chcomb4pchan[] = { +static const enum gsm_phys_chan_config chcomb4pchan[] = { [GSM_PCHAN_NONE] = 0xff, [GSM_PCHAN_CCCH] = NM_CHANC_mainBCCH, [GSM_PCHAN_CCCH_SDCCH4] = NM_CHANC_BCCHComb, @@ -430,7 +430,7 @@ int abis_nm_chcomb4pchan(enum gsm_phys_chan_config pchan) } /*! \brief Obtain physical channel config for OML Channel Combination */ -enum abis_nm_chan_comb abis_nm_pchan4chcomb(uint8_t chcomb) +enum gsm_phys_chan_config abis_nm_pchan4chcomb(uint8_t chcomb) { int i; for (i = 0; i < ARRAY_SIZE(chcomb4pchan); i++) {

1 0

None
by None 03 Jan '22

03 Jan '22

<div><br></div><div>" #if defined(L1_HAS_EFR) && defined(USE_L= 1_RTP_MODE) "</div><div><br></div><div>is why I'm seeing this mess= age logged, but it seems to be #define...</div><div><br></div><div>Any poin= ters, ideas ? This doesn't seem like a configuration thing, but a compi= lation time option?</div> <div>I'd have expected that EFR is fully supported?</div><div><br></div= ><div><br></div><div>osmo-bts.cfg snippet</div><div>-----------------------= -------</div><div><div>bts 0</div><div>=A0band 850</div><div>=A0ipa unit-id= 1801 0</div> <div>=A0oml remote-ip 127.0.0.1</div><div>=A0rtp jitter-buffer 100</div><di= v>=A0paging queue-size 200</div><div>=A0paging lifetime 0</div><div>=A0trx = 0</div><div>=A0 clock-calibration 603</div><div>=A0 trx-calibration-path (n= ull)</div> <div>=A0 clock-source ocxo</div><div>=A0 uplink-power-target -75</div><div>= =A0 min-qual-rach -5</div><div>=A0 min-qual-norm -5</div></div><div><br></d= iv><div><br></div><div><br></div><div>Regards,</div><div>Roelf.</div><div><= br></div> </div> --bcaec51b1b6f7f08e204e11a4392--

1 0

None
by None 03 Jan '22

03 Jan '22

I deduct that " #if defined(L1_HAS_EFR) && defined(USE_L1_RTP_MODE) " is why I'm seeing this message logged, but it seems to be #define... Any pointers, ideas ? This doesn't seem like a configuration thing, but a compilation time option? I'd have expected that EFR is fully supported? osmo-bts.cfg snippet ------------------------------ bts 0 band 850 ipa unit-id 1801 0 oml remote-ip 127.0.0.1 rtp jitter-buffer 100 paging queue-size 200 paging lifetime 0 trx 0 clock-calibration 603 trx-calibration-path (null) clock-source ocxo uplink-power-target -75 min-qual-rach -5 min-qual-norm -5 Regards, Roelf. --bcaec51b1b6f7f08e204e11a4392 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>I have FINALLY gotten to play with my sysmoBTS acquired many months ag= o, and updated to the latest packages using okpg, and am running a NITB.</d= iv><div><br></div><div>GSM850 test setup in open mode A5/0, and I can SMS a= nd call between devices.</div> <div><br></div><div>However, there is no audio, and BTS console logs report= s many repeats of the following during an established call.</div><div><br><= /div><0006> tch.c:601 (bts=3D0,trx=3D0,ts=3D7,ss=3D0) Rx Payload Type= EFR is unsupported<div> <0006> tch.c:601 (bts=3D0,trx=3D0,ts=3D7,ss=3D0) Rx Payload Type EFR = is unsupported</div><div><0006> tch.c:601 (bts=3D0,trx=3D0,ts=3D7,ss= =3D0) Rx Payload Type EFR is unsupported</div><div><br><div><br></div><div>=

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC January 2022