OpenBSC

openbsc@lists.osmocom.org

8 participants
4276 discussions

Checking out LimeSDR Mini with osmocom. It seems good!!
by Gullik Webjorn 18 Jan '19

18 Jan '19

Tue 15-jan-2019 LimeSDR transmit check. Fired up old HP 8614A signal generator at 1880 Mhz, and let it stabilize for 1 hour. Level measurement after adjusting ALC, 0dBm = -0.4 dBm as checked with spectrum analyzer Checked level with HP L423A probe. Check of LimeSDR mini output. Output as seen on spectrum analyzer -1.0 dBm. This correlates with LMS7002 datasheet with a possible 1 dB loss between chip and analyzer, including SMA-BNC coax adapter, 2 m foam insulated RG58 size cable, BNC - N connector. So, for practical purposes the LimeSDR mini provides 0 dBm ( +/- 1.4 dBm ) LimeSDR receive check. Receive antenna rigged with a 1/10 dB splitter, -10 dB port connected to spectrum analyzer, -1 dB port to LimeSDR. Connect single Nokia Handset, and make a call from osmobsc to fixed phone, so that only one mobile is using TCH. Move phone to get different uplink levels and correlate these to spectrum analyzer. Since carrier is TDMA, use peak hold on analyzer. Active subscriber connections: conn ID=31, MSC=0, hodec2_fail=0, mgw_ep=rtpbridge/1@mgw BTS 1, TRX 0, Timeslot 1, Lchan 0: Type TCH_F Connection: 1, State: ESTABLISHED BS Power: 10 dBm, MS Power: 10 dBm Channel Mode / Codec: SPEECH_V1 No Subscriber Bound IP: 192.168.1.75 Port 16384 RTP_TYPE2=0 CONN_ID=0 Conn. IP: 192.168.1.70 Port 4110 RTP_TYPE=3 SPEECH_MODE=0x00 Measurement Report: Flags: MS Timing Offset: 0 L1 MS Power: 10 dBm, Timing Advance: 4 RXL-FULL-dl: -51 dBm, RXL-SUB-dl: -51 dBm RXQ-FULL-dl: 0, RXQ-SUB-dl: 0 RXL-FULL-ul: -54 dBm, RXL-SUB-ul: -54 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 Level on uplink -54 dBm, indicated on spectrum analyzer -53 (-63) dBm. OsmoBSC# show conn Active subscriber connections: conn ID=31, MSC=0, hodec2_fail=0, mgw_ep=rtpbridge/1@mgw BTS 1, TRX 0, Timeslot 1, Lchan 0: Type TCH_F Connection: 1, State: ESTABLISHED BS Power: 10 dBm, MS Power: 10 dBm Channel Mode / Codec: SPEECH_V1 No Subscriber Bound IP: 192.168.1.75 Port 16384 RTP_TYPE2=0 CONN_ID=0 Conn. IP: 192.168.1.70 Port 4110 RTP_TYPE=3 SPEECH_MODE=0x00 Measurement Report: Flags: MS Timing Offset: 0 L1 MS Power: 10 dBm, Timing Advance: 4 RXL-FULL-dl: -69 dBm, RXL-SUB-dl: -69 dBm RXQ-FULL-dl: 0, RXQ-SUB-dl: 0 RXL-FULL-ul: -59 dBm, RXL-SUB-ul: -59 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 Mobile moved to another location within the lab. Level on uplink -59 dBm, indicated on spectrum analyzer -60 (-70) dBm. Conclusion: For such a simple low cost SDR, the accuracy seems within a couple of dB. Instruments used were are not "professional grade", at least not w.r. 2019, but I estimate I can measure within +/- 2 dB or so with this crude config. Power output is 10 times lower than I expected, I was probably mislead by some review on the web, and had to go down to the actual scematic and datasheet to understand that the expected level should be around 0 dBm. (thanks for pointing this out, Harald) For practical use outside a lab output is far too low. My plan is to add a small simple booster to bring level up to +15 which would allow me to cover my 2 acre lot without breaking any rules. Else, I am impressed, good value for a low price tag. I had expected far worse than indicated accuracy. Best Regards, Gullik

2 2

Re: Re: Re: OsmoTRX - osmo-trx-usrp-1 Aborted :: Assertion 'px != 0' failed
by Sergey Mayzus 17 Jan '19

17 Jan '19

1 0

osmo-hlr db upgrade behavior poll
by Neels Hofmeyr 17 Jan '19

17 Jan '19

Hi all, when reviewing osmo-hlr db schema upgrades, I came up with the idea that we shouldn't upgrade automatically. That's why, for schema updates, osmo-hlr now refuses to start and requires one start with the --db-upgrade option. Our systemd service file does not include that option. The result is that after an upgraded osmo-hlr binary, admins may have to take extra action to upgrade the DB. The rationale is that if someone by accident launches a newer osmo-hlr only once, with automatic upgrade the user is then stuck with the newer version DB, since we don't make a backup and we don't provide a downgrade path. I'm now wondering whether that is really necessary. In the daily churn, it creates noise. How to make this less noisy? - Users could add the --db-upgrade option to the service file to always upgrade. (But it is cumbersome to have a .service file that differs from the installed version) - We could also add a cfg file option to allow-db-upgrades. - We could drop the behavior and always upgrade. In the lack of strong opinions, this will probably stay as it is. I'd just like to hear what you guys think about it. Is it annoying or a good idea? Thanks! ~N

4 4

default TA vty config for OSMO-PCU?
by Keith 17 Jan '19

17 Jan '19

Hey list.. so i want to do some experiments setting the default TA in the PCU to the distance from the tower to the main population centre, rather than have it set to 220 (invalid) So, this email is not about the details of that issue, rather just a quick question. In the interim while this gets finally done right, would we accept adding a default-timing-advance param to the vty config? Otherwise I can patch and compile version for each BTS, but the vty config would be WAY more handy! thnx k/

2 2

SMS Sender Name Using Alphanumeric Characters
by Ron 15 Jan '19

15 Jan '19

Hi Community, Is it possible to send SMS using alphanumeric characters as a sender address? We tried it using an Open-Source SMS GW and it can send alphanumeric information in the sender address. Unfortunately, the SMS sent through API was not received to the test phone and the logs below are seen in OSMO-MSC. <000c> smpp_smsc.c:729 [entropy] Rx SUBMIT-SM (09170000023/1/1) <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. We also tried sending SMS with only Numeric information in the sender address and the SMS was received successfully by the test phone. We can share the traces taken and the configurations used if needed. TIA. Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

3 5

A ramble about MSC, sip-connector and asterisk.
by Gullik Webjorn 15 Jan '19

15 Jan '19

Hi, Some weeks ago I managed to integrate osmobts with my asterisk server. In the beginning, I did not get any call progress, ( as opposed to running WITHOUT asterisk ). I realized that defining the msc to sipconnector socket effectively disabled all the logic related to this. To remedy the situation, I set an asterisk "progress statement" whenever the extensions.conf indicated a number belonging to my GSM network. This works OK, but now, I don't get call progress on calls toward PSTN. These extensions do not have "progress" statements, since all SIP phones interpret the call progress sip messages such as RINGING. I am interested in your comments whether msc + sipconnector should emulate mobiles as "sip phones", it does seem to just silently drop call progress messages, and is this the way it should work? The functionality IS there, since when osmobts was bridging the calls, call progress WAS there. Well, I kludged up a solution for the GSM-only situation, and this seems suboptimal. I guess some clever asterisk hacking would solve that, possibly having a redundant progress statement on ALL extensions would do it, but would I not lose "actual" call progress signals from the PSTN, since asterisk would emulate them? Another way would be a small "local" asterisk.....before the *real* one. Boldly moving on to MultiBTS and handover.... Gullik

4 4

OsmoTRX + LimeSDR + Pine64
by Alex 14 Jan '19

14 Jan '19

Hi everyone, I'm facing a little strange problem with latest version of OsmoTRX and LimeSDR on a Pine64 board. I've built everything from source (latest git commit) Here is the console output of osmo-trx-lms root@pine64:~/osmo-trx# osmo-trx-lms -C /opt/osmocom/etc/osmo-trx-limesdr.cfg Sun Jan 13 22:11:40 2019 DLGLOBAL <0004> telnet_interface.c:104 Available via telnet 127.0.0.1 4237 Sun Jan 13 22:11:40 2019 DLCTRL <000b> control_if.c:911 CTRL at 127.0.0.1 4236 Sun Jan 13 22:11:40 2019 DMAIN <0000> osmo-trx.cpp:430 [tid=281473725702144] Config Settings Log Level............... 0 Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 GSM BTS Address......... 127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 4 EDGE support............ 0 Reference............... 0 C0 Filler Table......... 1 Multi-Carrier........... 0 Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 Tx Antennas............. 'BAND1' Rx Antennas............. 'LNAW' Sun Jan 13 22:11:40 2019 DDEV <0002> LMSDevice.cpp:68 [tid=281473725702144] creating LMS device... Sun Jan 13 22:11:40 2019 DDEV <0002> LMSDevice.cpp:156 [tid=281473725702144] Opening LMS device.. Sun Jan 13 22:11:40 2019 DDEV <0002> LMSDevice.cpp:162 [tid=281473725702144] Devices found: 1 Sun Jan 13 22:11:40 2019 DDEV <0002> LMSDevice.cpp:172 [tid=281473725702144] Device [0]: LimeSDR Mini, media=USB 2.0, module=FT601, addr=24607:1027, serial=1D4259C8DFD3CD Sun Jan 13 22:11:40 2019 DDEV <0002> LMSDevice.cpp:181 [tid=281473725702144] Using device[0] Sun Jan 13 22:11:40 2019 DLMS <0003> LMSDevice.cpp:102 [tid=281473725702144] Reference clock 40.00 MHz Sun Jan 13 22:11:40 2019 DDEV <0002> LMSDevice.cpp:191 [tid=281473725702144] Init LMS device Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:113 [tid=281473725702144] Sample Rate: Min=100000 Max=3.072e+07 Step=0 Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:201 [tid=281473725702144] Setting sample rate to 1.08333e+06 4 Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:207 [tid=281473725702144] Sample Rate: Host=1.08333e+06 RF=3.46667e+07 Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:214 [tid=281473725702144] Setting Internal clock reference Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:218 [tid=281473725702144] Setting VCTCXO to 180 Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:113 [tid=281473725702144] LPFBWRange Rx: Min=1.4001e+06 Max=1.3e+08 Step=0 Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:113 [tid=281473725702144] LPFBWRange Tx: Min=1.4001e+06 Max=1.3e+08 Step=0 Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:242 [tid=281473725702144] LPFBW: Rx=1.4001e+06 Tx=5.2e+06 Sun Jan 13 22:11:41 2019 DMAIN <0000> LMSDevice.cpp:203 [tid=281473725702144] Antennas configured successfully Sun Jan 13 22:11:41 2019 DDEV <0002> LMSDevice.cpp:251 [tid=281473725702144] Setting LPFBW chan 0 Sun Jan 13 22:11:44 2019 DLMS <0003> LMSDevice.cpp:102 [tid=281473725702144] RX LPF configured Sun Jan 13 22:11:44 2019 DLMS <0003> LMSDevice.cpp:102 [tid=281473725702144] Filter calibrated. Filter order-4th, filter bandwidth set to 5.2 MHz.Real pole 1st order filter set to 2.5 MHz. Preemphasis filter not active Sun Jan 13 22:11:44 2019 DLMS <0003> LMSDevice.cpp:102 [tid=281473725702144] TX LPF configured Sun Jan 13 22:11:44 2019 DDEV <0002> LMSDevice.cpp:256 [tid=281473725702144] Calibrating chan 0 Sun Jan 13 22:11:44 2019 DLMS <0003> LMSDevice.cpp:102 [tid=281473725702144] Rx calibration finished Sun Jan 13 22:11:44 2019 DLMS <0003> LMSDevice.cpp:102 [tid=281473725702144] Tx calibration finished osmo-trx-lms: Threads.cpp:133: void Thread::start(void* (*)(void*), void*): Assertion `!res' failed. signal 6 received talloc report on 'OsmoTRX' (total 3427 bytes in 17 blocks) telnet_connection contains 1 bytes in 1 blocks (ref 0) 0xf748b60 logging contains 3043 bytes in 9 blocks (ref 0) 0xf6c44f0 struct trx_ctx contains 383 bytes in 5 blocks (ref 0) 0xf6c4220 msgb contains 0 bytes in 1 blocks (ref 0) 0xf6c41b0 full talloc report on 'OsmoTRX' (total 3427 bytes in 17 blocks) telnet_connection contains 1 bytes in 1 blocks (ref 0) 0xf748b60 logging contains 3043 bytes in 9 blocks (ref 0) 0xf6c44f0 Configure logging Set the log level for a specified category Main generic category TRX CTRL interface Device/Driver specific code Logging from within LimeSuite itself Library-internal global log family LAPD in libosmogsm A-bis Intput Subsystem A-bis B-Subchannel TRAU Frame Multiplex A-bis Input Driver for Signalling A-bis Input Driver for B-Channels (voice) Layer3 Short Message Service (SMS) Control Interface GPRS GTP library Statistics messages and logging Generic Subscriber Update Protocol Osmocom Authentication Protocol libosmo-sigtran Signalling System 7 libosmo-sigtran SCCP Implementation libosmo-sigtran SCCP User Adaptation libosmo-sigtran MTP3 User Adaptation libosmo-mgcp Media Gateway Control Protocol libosmo-netif Jitter Buffer Deprecated alias for 'no logging level force-all' contains 798 bytes in 1 blocks (ref 0) 0xf7019a0 logging level (main|trxctrl|dev|lms|lglobal|llapd|linp|lmux|lmi|lmib|lsms|lctrl|lgtp|lstats|lgsup|loap|lss7|lsccp|lsua|lm3ua|lmgcp|ljibuf) everything contains 150 bytes in 1 blocks (ref 0) 0xf7017f0 Configure logging Set the log level for a specified category Main generic category TRX CTRL interface Device/Driver specific code Logging from within LimeSuite itself Library-internal global log family LAPD in libosmogsm A-bis Intput Subsystem A-bis B-Subchannel TRAU Frame Multiplex A-bis Input Driver for Signalling A-bis Input Driver for B-Channels (voice) Layer3 Short Message Service (SMS) Control Interface GPRS GTP library Statistics messages and logging Generic Subscriber Update Protocol Osmocom Authentication Protocol libosmo-sigtran Signalling System 7 libosmo-sigtran SCCP Implementation libosmo-sigtran SCCP User Adaptation libosmo-sigtran MTP3 User Adaptation libosmo-mgcp Media Gateway Control Protocol libosmo-netif Jitter Buffer Log debug messages and higher levels Log informational messages and higher levels Log noticeable messages and higher levels Log error messages and higher levels Log only fatal messages contains 933 bytes in 1 blocks (ref 0) 0xf7013e0 logging level (main|trxctrl|dev|lms|lglobal|llapd|linp|lmux|lmi|lmib|lsms|lctrl|lgtp|lstats|lgsup|loap|lss7|lsccp|lsua|lm3ua|lmgcp|ljibuf) (debug|info|notice|error|fatal) contains 171 bytes in 1 blocks (ref 0) 0xf701230 struct log_target contains 214 bytes in 2 blocks (ref 0) 0xf6c4940 struct log_category contains 46 bytes in 1 blocks (ref 0) 0xf6c4a50 struct log_info contains 776 bytes in 2 blocks (ref 0) 0xf6c4560 struct log_info_cat contains 736 bytes in 1 blocks (ref 0) 0xf6c45f0 struct trx_ctx contains 383 bytes in 5 blocks (ref 0) 0xf6c4220 LNAW contains 5 bytes in 1 blocks (ref 0) 0xf748fd0 BAND1 contains 6 bytes in 1 blocks (ref 0) 0xf748ec0 127.0.0.1 contains 10 bytes in 1 blocks (ref 0) 0xf6c4470 127.0.0.1 contains 10 bytes in 1 blocks (ref 0) 0xf6c43f0 msgb contains 0 bytes in 1 blocks (ref 0) 0xf6c41b0 Aborted Can someone provide me a little light on this? I've some doubts about the usb power output, but I'm facing this also with a powered usb hub. Thank you and best regards Alex

2 3

SMS Sender Name using Alphanumeric
by Ron 14 Jan '19

14 Jan '19

Hi Community, Is it possible to send SMS using alphanumeric information as a sender address? We tried it using an Open-Source SMS GW and it can send alphanumeric information in the sender address. Unfortunately, the SMS sent through API was not received to the test phone and the logs below are seen in OSMO-MSC. <000c> smpp_smsc.c:729 [entropy] Rx SUBMIT-SM (09170000023/1/1) <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. We also tried sending SMS with only Numeric information in the sender address and the SMS was received successfully by the test phone. Also attached in this email are the traces and configuration files used and taken during the testing. Kindly advice if we missed something in our configuration. TIA. Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

1 0

GSM MS Tx power levels (was Re: uncalibrated general-purpose SDRs (was Re: Balancing BTS'es for handover))
by Mychaela Falconia 14 Jan '19

14 Jan '19

Harald Welte wrote: > [...] the big difference is that the mobile has been calibrated to > (if I remember) 2dB accuracy, The GSM 05.05 spec indeed sets a tolerance of 2 dB under normal conditions or 2.5 dB under extreme conditions on the mobile station's maximum power output level for each band. These tolerances get looser for the lower power control level, up to 5 dB under normal conditions or 6 dB under extreme conditions for the lowest PCL. However, as someone who is intimately familiar with the actual calibration procedures performed by MS manufacturers (just did it myself less than 48 hours ago for a new batch of boards), I can tell you how it is actually done. There is a table of target power levels in dBm, and the calibration station goes through the full set of allowed PCLs (5-19 for EGSM and GSM850, or 0-15 for DCS and PCS) and steers the Tx power output (as measured by the test instrument, usually R&S CMU200) for each PCL to the dBm number in the table. But there is a hack in this setup which most MS manufacturers fail to disclose: with all GSM MS RF designs I have laid my hands on so far, including the one I've inherited from Openmoko (OK, I admit that all of my experience is with old stuff, not any of the recent stuff from MTK or Spreadtrum, but don't blame me, blame MTK and Spreadtrum for not publicly releasing their full chip docs and reference firmware source code), the MS hardware is oftentimes not actually capable of putting out the maximum power output prescribed by the spec (33 dBm for low bands or 30 dBm for high bands) while staying in the linear range of the PA (the range in which the relation between the APC control voltage and RF Vout is mostly linear), and thus the calibration procedure has to be fudged. In the case of Openmoko, they set the calibration targets for the highest power levels to 31.8 dBm and 28.8 dBm instead of 33/30 (for low and high bands, respectively), the next PCL down is set to 30.5/27.5 instead of 31/28, and then the proper official numbers from the spec further down. I have to do the same on my current GSM MS boards: when I tried putting out the full 33/30 dBm at the maximum PCL as the spec calls for, I can usually hit it if I crank the PA really high, but then it goes out of its linear range, and lacking better RF kung-fu, I have to assume that it's bad.. The maximum Tx power level fudging done by manufacturers in my or Openmoko's position is 1.2 dB, which is less than the spec tolerance of 2 dB, thus manufacturers like OM who did this fudging had no problems passing type approval tests, but I really wish I could find someone with more professional GSM MS design and manufacturing experience who could explain what actually happens, why we are not able hit the highest power levels while staying in the PA's linear range (the PA datasheet says it can put out 34.2 dBm in the low bands and 32.0 dBm in the high bands), and how the RF hw design might be improved so we can put out the highest power levels without fudging. Aside from the just-described fudging, the actual calibration tolerance (the maximum error between what the calibration procedure aims for and what actually comes out as measured by the CMU200) is less than 0.7 dB - and those ~0.5-0.6 dB errors happen mostly toward the lower power levels where the spec tolerances are the loosest; the maximum power level is calibrated to the shifted target number to better than 0.1 dB. M~

1 0

Balancing BTS'es for handover
by Gullik Webjorn 14 Jan '19

14 Jan '19

Below is a measurement on my "most distant" BTS, BTS 1. From what I see, downlink is 35 dB below uplink, which of course is natural when the MS can produce 30 dBm, and the BTS which in this case uses a bareback Limesdr min, can only produce 10 dBm. the bsc parameter ms max power is set to 15 for both bts 0 and bts 1. However, it seems MS output power is *much* stronger. Further, my understanding is that it is the BTS level measurements that decides when to handover, i.e. measurements in the upstream, and not the MS receive levels... Since there is such a mismatch between the micro BTS and the MS, maybe the RX should be attenuated, to bring upsteram levels more equal to downstream. OsmoBSC# show conns Active subscriber connections: conn ID=6, MSC=0, hodec2_fail=0, mgw_ep=rtpbridge/1@mgw BTS 0, TRX 0, Timeslot 1, Lchan 0: Type TCH_F Connection: 1, State: ESTABLISHED BS Power: 20 dBm, MS Power: 16 dBm Channel Mode / Codec: SPEECH_V1 No Subscriber Bound IP: 127.0.0.1 Port 16390 RTP_TYPE2=0 CONN_ID=0 Conn. IP: 192.168.1.70 Port 4186 RTP_TYPE=3 SPEECH_MODE=0x00 Measurement Report: Flags: MS Timing Offset: 0 L1 MS Power: 16 dBm, Timing Advance: 0 RXL-FULL-dl: -110 dBm, RXL-SUB-dl: -110 dBm RXQ-FULL-dl: 5, RXQ-SUB-dl: 5 RXL-FULL-ul: -74 dBm, RXL-SUB-ul: -73 dBm RXQ-FULL-ul: 3, RXQ-SUB-ul: 1 What are *your* experiences with "power control" and with "handover". Best Regards, Gullik

3 5

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC