OpenBSC

openbsc@lists.osmocom.org

4315 discussions

Start a nNew thread

Nanobts 1900 for sale
by Pierre Kim 10 Sep '13

10 Sep '13

Hello, I have a nanoBTS 1900MHz GPRS model for sale. Please email me if interested. Regards, Pierre

1 0

[PATCH 1/2] vty: Replace 'enum node_type' by 'int' for last_node
by Jacob Erlbeck 10 Sep '13

10 Sep '13

In this case the last_node variable may hold values that are not in enum node_type, so int is used instead. --- src/vty/command.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/vty/command.c b/src/vty/command.c index df2ffea..7f76ced 100644 --- a/src/vty/command.c +++ b/src/vty/command.c @@ -2291,7 +2291,7 @@ gDEFUN(config_exit, config_end_cmd, "end", "End current mode and change to enable mode.") { if (vty->node > ENABLE_NODE) { - enum node_type last_node = CONFIG_NODE; + int last_node = CONFIG_NODE; /* Repeatedly call go_parent until a top node is reached. */ while (vty->node > CONFIG_NODE) { -- 1.7.9.5

2 4

[PATCH 1/3] vty: Rename is_config() to is_config_child()
by Jacob Erlbeck 08 Sep '13

08 Sep '13

The function is_config() returns 0 for CONFIG_NODE. Since that node is a config node, the function is renamed to resolve this. --- src/vty/command.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/vty/command.c b/src/vty/command.c index faa7c51..7f502db 100644 --- a/src/vty/command.c +++ b/src/vty/command.c @@ -147,7 +147,7 @@ static int cmp_desc(const void *p, const void *q) return strcmp(a->cmd, b->cmd); } -static int is_config(struct vty *vty) +static int is_config_child(struct vty *vty) { if (vty->node <= CONFIG_NODE) return 0; @@ -2050,7 +2050,7 @@ cmd_execute_command(vector vline, struct vty *vty, struct cmd_element **cmd, /* Go to parent for config nodes to attempt to find the right command */ while (ret != CMD_SUCCESS && ret != CMD_WARNING - && is_config(vty)) { + && is_config_child(vty)) { vty_go_parent(vty); ret = cmd_execute_command_real(vline, vty, cmd); tried = 1; @@ -2198,7 +2198,7 @@ int config_from_file(struct vty *vty, FILE * fp) /* Try again with setting node to CONFIG_NODE */ while (ret != CMD_SUCCESS && ret != CMD_WARNING && ret != CMD_ERR_NOTHING_TODO - && vty->node != CONFIG_NODE && is_config(vty)) { + && is_config_child(vty)) { vty_go_parent(vty); ret = cmd_execute_command_strict(vline, vty, NULL); } -- 1.7.9.5

2 4

OpenBSC with A-interface
by Dmitri Soloviev 07 Sep '13

07 Sep '13

Hi list, Peter, thank you for your reply. I still have questions about media control: 1) when parsing MGCP CRCX, sdp is not expected. May I change it? 2) I still can't run media in BSC mode. Seems I'm missing something. osmo-bsc and osmo-bsc_mgcp are running BSSAP works perfectly But it seems two interfaces are working completely independent: -- MGCP between MSC and BSC -- interface between BSC and BTS (ip.access): at MGCP, connection is acknowledged, endpoint is allocated (at BSC ip=192.168.1.11) at ip.access interface between BSC and BTS, BTS replies to ip.accessCRCX with proper acknowledgement with proper ip:port at BTS (192.168.1.9) , then BSC issues ip.accessMDCX with endpoint ip zero: 7e:73:01:09:f8:00:2d:*f0:00:00:00:00*:f1:0f:be:f4:00:f2:03 My attempts to modify connection at MGCP interface has no impact on ip.access interface The key question, I'm not getting how osmo-bsc and osmo0bsc_mgcp are interacting. Thank you, Dmitri PS my configs are mgcp local ip 192.168.1.11 bts ip 192.168.1.9 bind ip 192.168.1.11 bind port 2427 rtp base 6000 sdp audio payload number 3 sdp audio payload name GSM/8000 number endpoints 31 and e1_input e1_line 0 driver ipa network network country code 250 mobile network code 07 short name OsmoBSC long name OsmoBSC auth policy closed location updating reject cause 13 ! encryption a5 1 neci 1 paging any use tch 0 rrlp mode none mm info 1 handover 0 handover window rxlev averaging 10 handover window rxqual averaging 1 handover window rxlev neighbor averaging 10 handover power budget interval 6 handover power budget hysteresis 3 handover maximum distance 9999 timer t3101 10 timer t3103 0 timer t3105 0 timer t3107 0 timer t3109 0 timer t3111 0 timer t3113 60 timer t3115 0 timer t3117 0 timer t3119 0 timer t3122 0 timer t3141 0 dtx-used 0 subscriber-keep-in-ram 0 bts 0 type nanobts band PCS1900 cell_identity 2611 location_area_code 51601 training_sequence_code 7 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 channel allocator ascending rach tx integer 9 rach max transmission 7 ip.access unit_id 1801 0 oml ip.access stream_id 255 line 0 neighbor-list mode manual-si5 gprs mode none trx 0 rf_locked 0 arfcn 810 nominal power 0 max_power_red 20 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 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 msc ! ip.access rtp-base 6000 timeout-ping 20 timeout-pong 5 dest 192.168.50.10 5000 0 in fact, BSSAP goes from a card over VPN, while MGCP comes from self-written TRAU running locally, the same host as BSC

3 6

l1-sap patches for osmo-bts
by Andreas Eversberg 04 Sep '13

04 Sep '13

hi, i reworked my l1sap patches for osmo-bts. (they are the base for adding osmo-bts-trx model code, which allow support for OpenBTS transceivers, like UmTRX or Calypso-BTS.) each single patch was tested, if Sysmocom-BTS is still functioning after applying it, rather than testing all patches together. i do not send the patches to mailing list, since there are 21 patches, and i don't want to spam the list before i know that these patches are small enough to be reviewed and understood. the branch is jolly/l1sap_parts. please let me know, whether they require better description or finer splitting. regards, andreas from last path to first patch: commit 0c0229886f6f6eba029c044e4cac8b420d86cd1c Author: Andreas Eversberg <jolly(a)eversberg.eu> Date: Sun Sep 1 12:30:52 2013 +0200 Remove obsolete gsmtap handling from osmo-bts-sysmo part. commit dfc8a3635e527960fa615c4ce7342e9739230a79 Author: Andreas Eversberg <jolly(a)eversberg.eu> Date: Sun Jun 16 15:09:56 2013 +0200 sysmobts: Forward CMR from L1 (Phone) to RTP payload commit 8cfffc712914107fe8277c96ad3afb1891f25014 Author: Andreas Eversberg <jolly(a)eversberg.eu> Date: Sun Sep 1 12:06:19 2013 +0200 Add gsmtap option to command line to main.c of osmo-bts-sysmo commit 8ca47efb9cf9861a2766c41b96469263e1e13ed9 Author: Andreas Eversberg <jolly(a)eversberg.eu> Date: Sun Sep 1 12:04:49 2013 +0200 Move gsmtap VTY commands from osmo-bts-sysmo to common part commit 2653aee1604d1504d707c9ed264dcb5cdaf2b01d Author: Andreas Eversberg <jolly(a)eversberg.eu> Date: Mon Jul 29 09:45:22 2013 +0200 Send primitives at PH-/MPH-/TCH-SAP interface via GSMTAP commit 66c08e87a2985ffd48e6d870ac6318c2b82a1476 Author: Andreas Eversberg <jolly(a)eversberg.eu> Date: Sun Sep 1 11:57:07 2013 +0200 Move loopback control VTY commands from osmo-bts-sysmo to common part commit 8015bfcb3014c707bfe16ed4b52612e6fe377e75 Author: Andreas Eversberg <jolly(a)eversberg.eu> Date: Thu Feb 14 11:17:58 2013 +0100 Correctly fill system information messages from BSC SI 5*/6 require L2 header of 0x03,0x03. All SI might be less than 23 octets, so they need to be filled with 0x2b. commit ebc180d0270293195c830193234608629b50bc03 Author: Andreas Eversberg <jolly(a)eversberg.eu> Date: Sun Jun 16 13:26:14 2013 +0200 sysmobts: Clean up transitions for lchan cipher state There are three transitions: 1. LCHAN_CIPH_NONE -> LCHAN_CIPH_RX_REQ -> LCHAN_CIPH_RX_CONF It is used to enable ciphering in RX (uplink) direction only. 2. LCHAN_CIPH_RX_CONF -> LCHAN_CIPH_RX_CONF_TX_REQ -> LCHAN_CIPH_RXTX_CONF It is used to additionally enable ciphering in TX (downlink) direction. 3. LCHAN_CIPH_NONE -> LCHAN_CIPH_RXTX_REQ -> LCHAN_CIPH_RX_CONF_TX_REQ -> LCHAN_CIPH_RXTX_CONF It is used to enable ciphering in both TX and RX directions. This is used when the channel is activated with encryption already enabled. (assignment or handover) In order to follow the order of these transitions, the RX direction must always be set before the TX direction. If no cipher key is set (A5/0), ciphering is set to ALG 0, but lchan cipher state remains at LCHAN_CIPH_NONE. commit c5f478d8d6702961dfb74642108187e653a05775 Author: Andreas Eversberg <jolly(a)eversberg.eu> Date: Sat Aug 31 20:30:40 2013 +0200 Add MEAS (MPH_INFO) IND message to PH-/MPH-/TCH-SAP interface This part moves processing of measurement infos from osmo-bts-sysmo to common part. commit ffc1cc39ea28b695b98eedd1d16bdd023e4a77ad Author: Andreas Eversberg <jolly(a)eversberg.eu> Date: Sun Sep 1 11:09:20 2013 +0200 Add SDCCH/SACCH/FACCH messages to PH-/MPH-/TCH-SAP interface This part moves control channel message primitives from osmo-bts-sysmo to common part. In order to control ciphering fo BTS model, CIPHER (MPH_INFO) messages are used. commit adc84b8db3bff29b5c681e04e078ee6000e5f4bf Author: Andreas Eversberg <jolly(a)eversberg.eu> Date: Sun Sep 1 10:08:15 2013 +0200 Add TCH messages to PH-/MPH-/TCH-SAP interface This part moves TCH handling from osmo-bts-sysmo to common part. The RTP handling is done at the common part, so they can be used by other BTS models. commit 2510e3f23ed4fa0a469484703c6b86574f175cdc Author: Andreas Eversberg <jolly(a)eversberg.eu> Date: Sun Sep 1 09:19:45 2013 +0200 Move chan act/rel/modify from bts_model to PH-/MPH-/TCH-SAP interface This part replaces channel activation/deactivation/modification routines by MPH_INFO messages. commit b1df874be87cf09290a3dd0d95790bc74f3d09fa Author: Andreas Eversberg <jolly(a)eversberg.eu> Date: Sun Sep 1 09:02:24 2013 +0200 Relace bts_model_get_time() by get_time() at common part commit f5b8b0de3303cefb06838991441e24c6d58e7aae Author: Andreas Eversberg <jolly(a)eversberg.eu> Date: Sat Aug 31 19:49:12 2013 +0200 Add TIME (MPH_INFO) IND messages to PH-/MPH-/TCH-SAP interface This part moves GSM time handling from osmo-bts-sysmo part to common part. commit a8d8eac3924517842c69a8d2b8ea4d8f17ce2c3a Author: Andreas Eversberg <jolly(a)eversberg.eu> Date: Fri Aug 30 08:48:38 2013 +0200 Add PDCH messages to PH-/MPH-/TCH-SAP interface This part moves PDTCH, PACCH and PTCCH message primitives from osmo-bts-sysmo to common part. commit ebcbe2f73078200317d5b8a134753a069f9c3572 Author: Andreas Eversberg <jolly(a)eversberg.eu> Date: Fri Aug 30 08:03:09 2013 +0200 Add PCH/AGCH message to PH-/MPH-/TCH-SAP interface This part moves PCH and AGCH message primitives from osmo-bts-sysmo to common part. commit 0521a5b654251fcd9a2923c607c8dbad3bd44a30 Author: Andreas Eversberg <jolly(a)eversberg.eu> Date: Fri Aug 30 07:46:30 2013 +0200 Add RACH message to PH-/MPH-/TCH-SAP interface This part moves RACH message primitives from osmo-bts-sysmo to common part. commit 2ee4f41d6c5fe78bb0c347e673e2411486f2bc3f Author: Andreas Eversberg <jolly(a)eversberg.eu> Date: Mon Jul 29 09:42:23 2013 +0200 Add BCCH message to PH-/MPH-/TCH-SAP interface This first part moves BCCH message primitives from osmo-bts-sysmo to common part. A new file "common/l1sap.c" is introduced to implement handling of layer 1 messages from/to BTS model. commit 4db570049f7ef6f7604e504083e8a3b751b09d6c Author: Andreas Eversberg <jolly(a)eversberg.eu> Date: Mon Jul 29 09:37:07 2013 +0200 Add header file of PH-/MPH-/TCH-SAP interface to common part of osmo-bts Instead of handling primitives directly at layer 1 specific code, osmo-bts handles primitives at common code. When all primitive are moved, the l1sap interface will: - receive PH-DATA indications and forward them to layer 2. - check for RF link loss and notify BSC. - receive TCH indications and forward them via RTP. - receive PH-RTS indications and send PH-DATA requests with content according to its logical channel. - receive TCH-RTS indications and send TCH requests with content received via RTP or loopback from TCH indications. - send MPH-INFO requests to activate, deactivate and modify logical channels and handle their confirms. - receive MPH-INFO indications with measurements from tranceiver. - forward received and transmitted PH-DATA to GSMTAP. commit ebb73d8cc333584d440398a7bed41f3584693f40 Author: Andreas Eversberg <jolly(a)eversberg.eu> Date: Sun Jul 28 11:48:40 2013 +0200 sysmo-bts: Use correct boundaries of L1 msg when forwarding to L1 proxy In case of a headroom in a message, the 'head' pointer will not point to the actual data. commit 2ef39102fed2167014938221411055a43a1dd763 Author: Andreas Eversberg <jolly(a)eversberg.eu> Date: Tue Feb 5 09:31:20 2013 +0100 Remove obsolete osmo-bts-bb code

2 2

[PATCH 1/6] vty: Fix BSC_NODE prompt string
by Jacob Erlbeck 02 Sep '13

02 Sep '13

Change '%s(bsc)#' to '%s(config-bsc)# '. The missing trailing blank brakes osmopy's VTYInteract.command() because the blank is contained in the end patterns which are checked to decide whether to leave the select loop. Thus trying to execute the 'bsc' command there blocks the test script forever. --- openbsc/src/osmo-bsc/osmo_bsc_vty.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openbsc/src/osmo-bsc/osmo_bsc_vty.c b/openbsc/src/osmo-bsc/osmo_bsc_vty.c index 8eaa55b..f6cf1a0 100644 --- a/openbsc/src/osmo-bsc/osmo_bsc_vty.c +++ b/openbsc/src/osmo-bsc/osmo_bsc_vty.c @@ -43,7 +43,7 @@ static struct osmo_msc_data *osmo_msc_data(struct vty *vty) static struct cmd_node bsc_node = { BSC_NODE, - "%s(bsc)#", + "%s(config-bsc)# ", 1, }; -- 1.7.9.5

2 18

Re: Bs11 problem on startup.
by choukoumoun 31 Aug '13

31 Aug '13

Hello, Where can download/find the *.SWL file for flash the BS11 ? Thanks bye On 12/06/2013 00:48, choukoumoun wrote: > Hello, > > Thanks you very much for your help (Love the open-source/hacker community) > I'll try that tomorrow and soon I will return. > > Bye! > > Le 12/06/2013 00:06, Sergey V. Efimov a écrit : >> Hello, >> >> Yep, it seems you need to reflash your BS11. You can start with >> "bs11_config -S" to download the safety file into the station if you >> have one. >> The next step is to download the real working firmware into the >> station. It can take up to 1,5 hours depending on the various conditions. >> You need to get several files, listed at >> http://openbsc.osmocom.org/trac/wiki/bs11_config, try to ask your seller. >> >> At the end of the flashing process (after reboot) you should see >> MBCCU0/MBCCU1 No Load / Load messages. >> >> Sergey. >> >> On Jun 12, 2013, at 1:48 AM, choukoumoun wrote: >> >>> Hello, >>> >>> it is the boot-up log for my Bs11 >>> >>> >>> >>> LMT LOGON: ACK >>> >>> PHASE: 1 load SMU Intended Abis-link: down >>> PHASE: 1 load SMU Intended Abis-link: down >>> PHASE: 1 load SMU Intended Abis-link: down >>> PHASE: 1 load SMU Intended Abis-link: down >>> PHASE: 1 load SMU Intended Abis-link: down >>> PHASE: 1 load SMU Intended Abis-link: down >>> PHASE: 1 load SMU Intended Abis-link: down >>> PHASE: 1 load SMU Intended Abis-link: down >>> PHASE: 1 load SMU Intended Abis-link: down >>> PHASE: 1 load SMU Intended Abis-link: down >>> PHASE: 1 load SMU Intended Abis-link: down >>> PHASE: 1 load SMU Intended Abis-link: down >>> PHASE: 1 load SMU Intended Abis-link: down >>> PHASE: 1 load SMU Intended Abis-link: down >>> PHASE: 1 load SMU Intended Abis-link: down >>> PHASE: 1 load SMU Intended Abis-link: down >>> PHASE: 1 load SMU Intended Abis-link: down >>> PHASE: 1 load SMU Intended Abis-link: down >>> PHASE: 1 load SMU Intended Abis-link: down >>> PHASE: 1 load SMU Intended Abis-link: down >>> PHASE: 1 Unknow Abis-link: down >>> PHASE: 1 Unknow Abis-link: down >>> PHASE: 1 Unknow Abis-link: down >>> PHASE: 1 Unknow Abis-link: down >>> PHASE: 1 Unknow Abis-link: down >>> PHASE: 1 Unknow Abis-link: down >>> PHASE: 1 Unknow Abis-link: down >>> PHASE: 1 Unknow Abis-link: down >>> PHASE: 1 Unknow Abis-link: down >>> PHASE: 1 Unknow Abis-link: down >>> PHASE: 1 Unknow Abis-link: down >>> PHASE: 1 Unknow Abis-link: down >>> PHASE: 1 Unknow Abis-link: down >>> PHASE: 1 Unknow Abis-link: down >>> PHASE: 1 Unknow Abis-link: down >>> PHASE: 1 Unknow Abis-link: down >>> PHASE: 1 Unknow Abis-link: down >>> PHASE: 1 Unknow Abis-link: down >>> >>> >>> Iawait yourreplywith great pleasure >>> >>> best, >>> Choukoumoun >>> >>> Le 10/06/2013 11:58, Sergey V. Efimov a écrit : >>>> Hello, >>>> >>>> I recall that something similar happened when I tried to monitor freshly received >>>> BS-11 without operating firmware. Could you please provide full boot-up log. >>>> >>>> Sergey. >>>> >>>> On Jun 10, 2013, at 1:36 AM, choukoumoun wrote: >>>> >>>>> Hello list, >>>>> >>>>> I have a problem with BS11 at startup: >>>>> >>>>> >>>>> When I put the BS11 voltage and that I connect in serial and I run: >>>>> >>>>> ./bs11_config-p / dev/ttyUSB0 query >>>>> >>>>> I like the result: >>>>> >>>>> >>>>> PHASE 1: unknown Abis-link: Down >>>>> >>>>> PHASE 1: unknown Abis-link: Down >>>>> >>>>> PHASE 1: unknown Abis-link: Down >>>>> >>>>> PHASE 1: unknown Abis-link: Down >>>>> >>>>> PHASE 1: unknown Abis-link: Down >>>>> >>>>> PHASE 1: unknown Abis-link: Down >>>>> >>>>> PHASE 1: unknown Abis-link: Down >>>>> >>>>> >>>>> constantly and eternally ...... >>>>> >>>>> Any idea?? >>>>> >>>>> >>>>> thank you >>>>> >>>>> >>> >>> >> >

1 0

[PATCH 2/8] Add MEAS (MPH_INFO) IND message to PH-/MPH-/TCH-SAP interface
by Andreas Eversberg 31 Aug '13

31 Aug '13

This part moves processing of measurement infos from osmo-bts-sysmo to common part. --- src/common/l1sap.c | 32 ++++++++++++++++++++++++++++++++ src/osmo-bts-sysmo/l1_if.c | 26 +++++++++++++------------- 2 files changed, 45 insertions(+), 13 deletions(-) diff --git a/src/common/l1sap.c b/src/common/l1sap.c index 9c7a9c6..c1e9f9f 100644 --- a/src/common/l1sap.c +++ b/src/common/l1sap.c @@ -155,6 +155,35 @@ static int l1sap_info_time_ind(struct gsm_bts_trx *trx, return 0; } +/* measurement information received from bts model */ +static int l1sap_info_meas_ind(struct gsm_bts_trx *trx, + struct osmo_phsap_prim *l1sap, + struct info_meas_ind_param *info_meas_ind) +{ + struct bts_ul_meas ulm; + struct gsm_lchan *lchan; + + DEBUGP(DL1P, "MPH_INFO meas ind chan_nr=%02x\n", + info_meas_ind->chan_nr); + + lchan = &trx->ts[L1SAP_CHAN2TS(info_meas_ind->chan_nr)] + .lchan[l1sap_chan2ss(info_meas_ind->chan_nr)]; + + /* in the GPRS case we are not interested in measurement + * processing. The PCU will take care of it */ + if (lchan->type == GSM_LCHAN_PDTCH) + return 0; + + memset(&ulm, 0, sizeof(ulm)); + ulm.ta_offs_qbits = info_meas_ind->ta_offs_qbits; + ulm.ber10k = info_meas_ind->ber10k; + ulm.inv_rssi = info_meas_ind->inv_rssi; + + lchan_new_ul_meas(lchan, &ulm); + + return 0; +} + /* any L1 MPH_INFO indication prim recevied from bts model */ static int l1sap_mph_info_ind(struct gsm_bts_trx *trx, struct osmo_phsap_prim *l1sap, struct mph_info_param *info) @@ -165,6 +194,9 @@ static int l1sap_mph_info_ind(struct gsm_bts_trx *trx, case PRIM_INFO_TIME: rc = l1sap_info_time_ind(trx, l1sap, &info->u.time_ind); break; + case PRIM_INFO_MEAS: + rc = l1sap_info_meas_ind(trx, l1sap, &info->u.meas_ind); + break; default: LOGP(DL1P, LOGL_NOTICE, "unknown MPH_INFO ind type %d\n", info->type); diff --git a/src/osmo-bts-sysmo/l1_if.c b/src/osmo-bts-sysmo/l1_if.c index 14efc2c..38daa97 100644 --- a/src/osmo-bts-sysmo/l1_if.c +++ b/src/osmo-bts-sysmo/l1_if.c @@ -891,20 +891,20 @@ static void dump_meas_res(int ll, GsmL1_MeasParam_t *m) m->fBer, m->i16BurstTiming); } -static int process_meas_res(struct gsm_lchan *lchan, GsmL1_MeasParam_t *m) +static int process_meas_res(struct gsm_bts_trx *trx, uint8_t chan_nr, + GsmL1_MeasParam_t *m) { - struct bts_ul_meas ulm; - - /* in the GPRS case we are not interested in measurement - * processing. The PCU will take care of it */ - if (lchan->type == GSM_LCHAN_PDTCH) - return 0; - - ulm.ta_offs_qbits = m->i16BurstTiming; - ulm.ber10k = (unsigned int) (m->fBer * 100); - ulm.inv_rssi = (uint8_t) (m->fRssi * -1); + struct osmo_phsap_prim l1sap; + memset(&l1sap, 0, sizeof(l1sap)); + osmo_prim_init(&l1sap.oph, SAP_GSM_PH, PRIM_MPH_INFO, + PRIM_OP_INDICATION, NULL); + l1sap.u.info.type = PRIM_INFO_MEAS; + l1sap.u.info.u.meas_ind.chan_nr = chan_nr; + l1sap.u.info.u.meas_ind.ta_offs_qbits = m->i16BurstTiming; + l1sap.u.info.u.meas_ind.ber10k = (unsigned int) (m->fBer * 100); + l1sap.u.info.u.meas_ind.inv_rssi = (uint8_t) (m->fRssi * -1); - return lchan_new_ul_meas(lchan, &ulm); + return l1sap_up(trx, &l1sap); } static int handle_ph_data_ind(struct femtol1_hdl *fl1, GsmL1_PhDataInd_t *data_ind, @@ -940,7 +940,7 @@ static int handle_ph_data_ind(struct femtol1_hdl *fl1, GsmL1_PhDataInd_t *data_i fn = data_ind->u32Fn; link_id = (data_ind->sapi == GsmL1_Sapi_Sacch) ? 0x40 : 0x00; - process_meas_res(lchan, &data_ind->measParam); + process_meas_res(trx, chan_nr, &data_ind->measParam); if (data_ind->measParam.fLinkQuality < fl1->min_qual_norm && data_ind->msgUnitParam.u8Size != 0) { -- 2.1.0 --PMULwz+zIGJzpDN9--

1 0

[PATCH] build: Don't llink with libbsc twice
by Alexander Chemeris 30 Aug '13

30 Aug '13

Hi, As the caption states, it removes duplicated library linkage. in tests/db/Makefile.am. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

2 3

SMPP Submit_SM sender address
by Alexander Chemeris 29 Aug '13

29 Aug '13

Hi Harald, We're trying out SMPP interconnection and found that for Submit_SM (aka MT-SMS) sender is always set to an extension of subscriber ID 1. Looking into the code, this happens because we set "sms->sender" to point to subscriber ID 1 in submit_to_sms() function in SMPP code: /* fill in the source address */ sms->sender = subscr_get_by_id(net, 1); sms->src.ton = submit->source_addr_ton; sms->src.npi = submit->source_addr_npi; strncpy(sms->src.addr, (char *)submit->source_addr, sizeof(sms->src.addr)-1); And then src.addr/ton/npi are ignored when we store to the SMS DB and only subscriber ID is stored: /* FIXME: correct validity period */ result = dbi_conn_queryf(conn, "INSERT INTO SMS " "(created, sender_id, receiver_id, valid_until, " "reply_path_req, status_rep_req, protocol_id, " "data_coding_scheme, ud_hdr_ind, dest_addr, " "user_data, text) VALUES " "(datetime('now'), %llu, %llu, %u, " "%u, %u, %u, %u, %u, %s, %s, %s)", sms->sender->id, sms->receiver ? sms->receiver->id : 0, validity_timestamp, sms->reply_path_req, sms->status_rep_req, sms->protocol_id, sms->data_coding_scheme, sms->ud_hdr_ind, q_daddr, q_udata, q_text); So when we read SMS back from the DB, sender address is taken from that subscriber. It seems that a solution is to store actual ton/npi/addr in the SMS DB instead of storing ID. Then we could set sms->sender to NULL and just ignore it. Is there anything wrong with this approach? Otherwise we'll work on a patch to implement that. PS What is the current policy about changing DB layouts - just increase SCHEMA_REVISION? -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

3 5

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC