OpenBSC February 2017

openbsc@lists.osmocom.org

22 participants
39 discussions

Heads-Up on ongoing libosmo-sccp SIGTRAN work
by Harald Welte 09 Feb '17

09 Feb '17

Dear all, so far libosmo-sccp had some code with a partial SCCP implementation that date back to the earliest day of OsmoBSC in 2009, done by Holger. It also contained a SUA implementation which (mostly) I did last year in the wake of the Iuh and IuCS/IuPS support for the Osmocom 3G support. The latter code is already more 'modern' and uses the osmocom primitives (osmo_prim) between the SCCP User (the application) and the SCCP Provider (the library). Those primitives are modelled after the related specifications. What I'm now wokring on is to get those last SUA related patches finally merged in master, and to * add missing ASPTM and ASPSM protocol code + osmo_fsm state machines in a generic way that they can be shared by all SIGTRAN xUA variants * add M3UA while sharing more code between SUA and M3UA * introduce a MTP SAP based on osmo_prim that can be used on top of M3UA * wrap the existing sccp.c code to use the MTP SAP on the lower end and the SCCP User SAP on the upper edge In the above implementations, I am aiming for implementing SGW, ASP and IPSP roles. However, primary focus is on ASP. In the end, we will be able to stack M3UA and SCCP code using primitives, and interact with the SCCP using the exact same primitives and API as we interact with SUA currently. This will give us: * true/real IuCS/IuPS suppotr (we currently do SUA, which is not as per spec) in OsmoCSCN, OsmoSGSN and OsmoHNBGW without any real modificatin of their code * a way towards 3GPP compliant AoIP, by using the SCCP User SAP from OsmoBSC. This means that we'll also have to add that SCCP User SAP to the SCCPlite/IPA code that OsmoBSC is using for now. While all of the above sounds great, it somehow hurts me that we have already some (partial?) implementations of M3UA in cellmgr-ng (particularly the osmo-stp application). It hurts me that I'm not able to use the code that Holger wrote in recent years, but I still think it's worth-while to do an implementation centered around osmo_prim for layer-boundaries and osmo_fsm for state machines. So my apologies to Holger on this. It's not "Not Invented Here" syndrome, but I think there are reasons to take a different route than the existing code. I'm of course also looking forward to hearing other opinions on that. [... and while I'm working on this, I also think about introducing some generic inter-layer primitive logging code, so we can enable logging of the primitives at a given SAP without the specific SAP implementation having to implement anything, like we do in terms of osmo_fsm logging] Regards, Harald -- - 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)

1 0

accelerate3g5 ML?
by Neels Hofmeyr 09 Feb '17

09 Feb '17

Will there be a separate mailing list for the accelerate3g5 "winners"? Maybe we could just make it a general osmocom-3G@ mailing list. Alternatively, we could use this list for 3G as well. What's the plan? ~N

2 1

Re: OpenBSC Digest, Vol 28, Issue 6
by Rajitha peiris 09 Feb '17

09 Feb '17

[cid:9b893015-fe6c-4d05-9933-7169f767fc97] ________________________________ From: OpenBSC <openbsc-bounces(a)lists.osmocom.org> on behalf of openbsc-request(a)lists.osmocom.org <openbsc-request(a)lists.osmocom.org> Sent: Thursday, February 9, 2017 9:00:47 AM To: openbsc(a)lists.osmocom.org Subject: OpenBSC Digest, Vol 28, Issue 6 Send OpenBSC mailing list submissions to openbsc(a)lists.osmocom.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request(a)lists.osmocom.org You can reach the person managing the list at openbsc-owner(a)lists.osmocom.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." Today's Topics: 1. Re: weekly test report (w5 2017) (Ivaylo Kostov) 2. Re: weekly test report (w5 2017) (Harald Welte) 3. Re: weekly test report (w5 2017) (Neels Hofmeyr) 4. Re: OpenBSC Digest, Vol 28, Issue 5 (Rajitha peiris) ---------------------------------------------------------------------- Message: 1 Date: Wed, 8 Feb 2017 16:33:26 +0100 From: Ivaylo Kostov <ikostov(a)sysmocom.de> To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de> Cc: Harald Welte <laforge(a)gnumonks.org>, openbsc(a)lists.osmocom.org Subject: Re: weekly test report (w5 2017) Message-ID: <06726d26-d66f-d48d-cf9d-533178a13ada(a)sysmocom.de> Content-Type: text/plain; charset=windows-1252; format=flowed Hi Neels, Yes. I do have TCH/F_PDCH dynamic timeslots in the test procedure. regards, Ivaylo On 08.02.2017 16:26, Neels Hofmeyr wrote: > (found this mail stuck in my outbox, sending late) > > On Mon, Feb 06, 2017 at 10:09:23AM +0100, Ivaylo Kostov wrote: >> Hi Harald, >> >> I see. What was communicated to me was that NITB channel configuration >> TCH/F_TCH/H_PDCH is not supported with nanoBTS. >> >> I will have in mind that nanoBTS does not support HR (v1) codec. > > Yes, we discussed TCH/F_TCH/H_PDCH for the nanoBTS. I remember to be surprised > because from some discussion it appeared that the nanoBTS supports HR, and I > was expecting TCH/F only. > > While talking about codecs, the ip.access nanoBTS *should* in fact support the > TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of > your testing procedure and add it if not? > > ~N > >-- ------------------------------ - Ivaylo Kostov <ikostov(a)sysmocom.de> <mailto:ikostov@sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte ------------------------------ ------------------------------ Message: 2 Date: Wed, 8 Feb 2017 16:45:57 +0100 From: Harald Welte <laforge(a)gnumonks.org> To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de> Cc: Ivaylo Kostov <ikostov(a)sysmocom.de>, openbsc(a)lists.osmocom.org Subject: Re: weekly test report (w5 2017) Message-ID: <20170208154557.2rmslkrzuqlv7xc4@nataraja> Content-Type: text/plain; charset=us-ascii Hi all, On Wed, Feb 08, 2017 at 04:26:11PM +0100, Neels Hofmeyr wrote: > While talking about codecs, the ip.access nanoBTS *should* in fact support the > TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of > your testing procedure and add it if not? libbsc should be extended to handle those restrictions, i.e. reject a configuration containing HR codec or a osmocom-style dynamic channel on a bts model 'nanobts'. Similarly, the BS11 should reject any codec except HRv1, FR and EFR (i.e. no AMR). In reality there are also older nanoBTSs that don't support AMR (as far as I remember), but that shouldn't prevent us from having at least the most basic checks in place. For osmo-bts, we need a more sophisticated hand-shaking mechanism, as there are many different hardware/PHYs (and associated versions) supported by it. This is left for further study ;) -- - 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) ------------------------------ Message: 3 Date: Thu, 9 Feb 2017 00:43:35 +0100 From: Neels Hofmeyr <nhofmeyr(a)sysmocom.de> To: Harald Welte <laforge(a)gnumonks.org> Cc: Ivaylo Kostov <ikostov(a)sysmocom.de>, openbsc(a)lists.osmocom.org Subject: Re: weekly test report (w5 2017) Message-ID: <20170208234335.GB27422(a)my.box> Content-Type: text/plain; charset="us-ascii" On Wed, Feb 08, 2017 at 04:45:57PM +0100, Harald Welte wrote: > libbsc should be extended to handle those restrictions, i.e. reject a > configuration containing HR codec or a osmocom-style dynamic channel on > a bts model 'nanobts'. i.e. checks on the VTY level. Seems like we want an issue for that: https://osmocom.org/issues/1946 ~N

2 2

osmo-bts-trx error with tch/h
by Max 09 Feb '17

09 Feb '17

Hi. There seems to be peculiar coding error with osmo-bts-trx and usrp b210: ... <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [0/0/0] <0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550946 ts=7 for TCH/H(1) <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [1/0/0] <0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550950 ts=7 for TCH/H(1) <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [0/0/0] <0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550955 ts=7 for TCH/H(1) <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [1/0/0] <0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550959 ts=7 for TCH/H(1) <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [0/0/0] ... The error seems to: - happen only on 2nd subslot of TCH/H - does not prevent calls establishement - let voice to go through The visible effect though is extra delay for call establishment when BSC allocates next available subslot - see https://projects.osmocom.org/issues/1795 for details. Have anyone else seen this? It could be that tch_hr_decode() screw up bits somehow while trying to decode stolen FACCH bits but the code seems rather arcane. For instance, when calling unmap (it actually just attempts to get hu(B) and hl(B) flags from 3GPP TS 45.003 §4.3.5 located in bits 58 and 57 correspondingly) potentially stolen bits in the beginning of function, why bursts 0..3 are treated as even and 2..4 as odd? -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

1 0

Re: OpenBSC Digest, Vol 28, Issue 5
by Rajitha peiris 09 Feb '17

09 Feb '17

Hello all can anyone send me a openbsc.cfg file for nanobts 1900pcs....? because still i am struck with my nanobts pcs1900.....i can send sms but no voice calls.....do i need to install mISDN and LCR for single bts ? .... thanks regards Rajitha Peiris Sri lanka ________________________________ From: OpenBSC <openbsc-bounces(a)lists.osmocom.org> on behalf of openbsc-request(a)lists.osmocom.org <openbsc-request(a)lists.osmocom.org> Sent: Wednesday, February 8, 2017 8:56:30 PM To: openbsc(a)lists.osmocom.org Subject: OpenBSC Digest, Vol 28, Issue 5 Send OpenBSC mailing list submissions to openbsc(a)lists.osmocom.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request(a)lists.osmocom.org You can reach the person managing the list at openbsc-owner(a)lists.osmocom.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." Today's Topics: 1. Re: MS cannot connect; Location Update Request not received by BTS (Hossein Amini) 2. Re: [PATCH net-next v2 2/6] gtp: merge gtp_get_net and gtp_genl_find_dev (Harald Welte) 3. Re: [PATCH net-next v2 1/6] gtp: make GTP sockets in gtp_newlink optional (Harald Welte) 4. Re: [PATCH net-next v2 4/6] gtp: consolidate pdp context destruction into helper (Harald Welte) 5. Re: [PATCH net-next v2 5/6] gtp: add socket to pdp context (Harald Welte) 6. Re: [PATCH net-next v2 3/6] gtp: unify genl_find_pdp and prepare for per socket lookup (Harald Welte) 7. Re: [PATCH net-next v2 0/6] gtp: misc improvements (Harald Welte) 8. Re: weekly test report (w5 2017) (Neels Hofmeyr) ---------------------------------------------------------------------- Message: 1 Date: Mon, 6 Feb 2017 16:45:40 +0330 From: Hossein Amini <hosseinamini2578(a)gmail.com> To: openbsc(a)lists.osmocom.org Subject: Re: MS cannot connect; Location Update Request not received by BTS Message-ID: <CAF81cShkO+JiamxQJXhqfpbOWxi9_8aEWsd5wTDhmZ0Vd912Xw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" I installed master branch now(4/feb/2017 at 18:30) and retry, but I can not release channel and receive error in nitb. I do not access to a external timing source like octoClock, do you use external timing source? do you have a easy solution to check that? My NITB log is like your log by 20170203014240662 and repeat. I retried connecting about 10 min but nothing happened. NITB log that repeat is: 20170204071216381 DRLL <0000> chan_alloc.c:352 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH 20170204071216381 DRSL <0004> abis_rsl.c:1819 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(0) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x06 ta=0 20170204071216381 DRSL <0004> abis_rsl.c:580 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL 20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED 20170204071216381 DRSL <0004> abis_rsl.c:1546 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK 20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE 20170204071226381 DRSL <0004> abis_rsl.c:852 (bts=0,trx=0,ts=0,ss=0) RF Channel Release due to error: 1 20170204071226381 DRSL <0004> abis_rsl.c:762 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD 20170204071226381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR 20170204071226382 DRSL <0004> abis_rsl.c:925 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK 20170204071228382 DRSL <0004> abis_rsl.c:811 (bts=0,trx=0,ts=0,ss=0) is back in operation. 20170204071228382 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE On Fri, Feb 3, 2017 at 2:28 AM, Neels Hofmeyr <neels(a)hofmeyr.de> wrote: > Dear Hossein, > > the mailing list is indeed the proper place to ask. If no-one replied to > your > question, it either means that no-one knows the answer, or that no-one has > found the time to look into it. Don't be discouraged by that. Indeed I > would > prefer if you ask again on the mailing list instead of asking single mail > addresses. I actually saw your mail on the list and did not know what to > answer. > > If you ask your question on-list again (possibly once a week), it might be > that > someone will come up with either an answer or with more questions that may > lead > you to a solution... > > I sincerely hope that you will find a solution. It seems to me that it's > merely > a minor detail. > > ~N > >

2 1

Re: MS cannot connect; Location Update Request not received by BTS
by Hossein Amini 06 Feb '17

06 Feb '17

I installed master branch now(4/feb/2017 at 18:30) and retry, but I can not release channel and receive error in nitb. I do not access to a external timing source like octoClock, do you use external timing source? do you have a easy solution to check that? My NITB log is like your log by 20170203014240662 and repeat. I retried connecting about 10 min but nothing happened. NITB log that repeat is: 20170204071216381 DRLL <0000> chan_alloc.c:352 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH 20170204071216381 DRSL <0004> abis_rsl.c:1819 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(0) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x06 ta=0 20170204071216381 DRSL <0004> abis_rsl.c:580 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL 20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED 20170204071216381 DRSL <0004> abis_rsl.c:1546 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK 20170204071216381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE 20170204071226381 DRSL <0004> abis_rsl.c:852 (bts=0,trx=0,ts=0,ss=0) RF Channel Release due to error: 1 20170204071226381 DRSL <0004> abis_rsl.c:762 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD 20170204071226381 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR 20170204071226382 DRSL <0004> abis_rsl.c:925 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK 20170204071228382 DRSL <0004> abis_rsl.c:811 (bts=0,trx=0,ts=0,ss=0) is back in operation. 20170204071228382 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE On Fri, Feb 3, 2017 at 2:28 AM, Neels Hofmeyr <neels(a)hofmeyr.de> wrote: > Dear Hossein, > > the mailing list is indeed the proper place to ask. If no-one replied to > your > question, it either means that no-one knows the answer, or that no-one has > found the time to look into it. Don't be discouraged by that. Indeed I > would > prefer if you ask again on the mailing list instead of asking single mail > addresses. I actually saw your mail on the list and did not know what to > answer. > > If you ask your question on-list again (possibly once a week), it might be > that > someone will come up with either an answer or with more questions that may > lead > you to a solution... > > I sincerely hope that you will find a solution. It seems to me that it's > merely > a minor detail. > > ~N > >

1 0

Downtime due FreeBSD upgrade.
by Holger Freyther 05 Feb '17

05 Feb '17

Hi, the machine hosting most of *.osmocom.org is running FreeBSD9.3 which EOLed end of december and I would like to upgrade to FreeBSD10.3. I do not expect many problems but I also don't want to interfere with other peoples work. Even if it is short notice, any objections for Saturday->Sunday night of a European timezone? Otherwise I would pick next Friday->Saturday. regards holger

2 2

Channel release error when osmo-nitb want execute location update
by Hossein Amini 03 Feb '17

03 Feb '17

hi dear I install openbsc, osmosgsn, ggsn, osmo-trx, osmo-bts-trx, osmo-pcu and dependency from master branch step by step from this link. <https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS> but when run osmo-nitb, osmo-trx and osmo-bts-trx, mobile connect to network but no access to network. (I used USRP N210/B210, ubuntu 15.10/16.10 64x) osmo-nitb log: 20170130041914525 DRLL <0000> chan_alloc.c:352 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH 20170130041914525 DRSL <0004> abis_rsl.c:1819 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(0) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x05 ta=0 20170130041914525 DRSL <0004> abis_rsl.c:580 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL 20170130041914525 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED 20170130041914525 DRSL <0004> abis_rsl.c:1546 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK 20170130041914525 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE 20170130041924529 DRSL <0004> abis_rsl.c:852 (bts=0,trx=0,ts=0,ss=0) RF Channel Release due to error: 1 20170130041924529 DRSL <0004> abis_rsl.c:762 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD 20170130041924529 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR 20170130041924530 DRSL <0004> abis_rsl.c:925 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK 20170130041926530 DRSL <0004> abis_rsl.c:811 (bts=0,trx=0,ts=0,ss=0) is back in operation. 20170130041926531 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE NITB config: ! ! OpenBSC (0.15.0.646-f1886-dirty) configuration saved from vty !! password foo ! log stderr logging filter all 1 logging color 1 logging print category 1 logging print extended-timestamp 1 logging level all everything logging level rll debug logging level cc debug logging level mm info logging level rr info logging level rsl debug logging level nm debug logging level mncc debug logging level pag debug logging level meas notice logging level sccp notice logging level msc notice logging level mgcp notice logging level ho notice logging level db notice logging level ref notice logging level gprs notice logging level ns info logging level bssgp notice logging level llc notice logging level sndcp notice logging level nat notice logging level ctrl notice logging level smpp notice logging level filter notice logging level ranap debug logging level sua debug logging level lglobal notice logging level llapd notice logging level linp notice logging level lmux notice logging level lmi notice logging level lmib notice logging level lsms notice logging level lctrl notice logging level lgtp notice logging level lstats notice logging level lgsup notice logging level loap notice ! stats interval 5 ! line vty no login ! e1_input e1_line 0 driver ipa e1_line 0 port 0 no e1_line 0 keepalive ipa bind 127.0.0.1 network network country code 432 mobile network code 70 short name dynch long name dynch auth policy accept-all authorized-regexp .* location updating reject cause 13 encryption a5 0 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 4 timer t3111 0 timer t3113 60 timer t3115 0 timer t3117 0 timer t3119 0 timer t3122 10 timer t3141 0 subscriber-keep-in-ram 0 bts 0 type sysmobts band GSM900 cell_identity 0 location_area_code 1 base_station_id_code 63 ms max power 15 cell reselection hysteresis 4 rxlev access min 0 periodic location update 30 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 early-classmark-sending forbidden ip.access unit_id 1800 0 oml ip.access stream_id 255 line 0 neighbor-list mode automatic codec-support fr gprs mode gprs gprs 11bit_rach_support_for_egprs 0 gprs routing area 0 gprs network-control-order nc1 gprs cell bvci 1800 gprs cell timer blocking-timer 3 gprs cell timer blocking-retries 3 gprs cell timer unblocking-retries 3 gprs cell timer reset-timer 3 gprs cell timer reset-retries 3 gprs cell timer suspend-timer 10 gprs cell timer suspend-retries 3 gprs cell timer resume-timer 10 gprs cell timer resume-retries 3 gprs cell timer capability-update-timer 10 gprs cell timer capability-update-retries 3 gprs nsei 1800 gprs ns timer tns-block 3 gprs ns timer tns-block-retries 3 gprs ns timer tns-reset 3 gprs ns timer tns-reset-retries 3 gprs ns timer tns-test 30 gprs ns timer tns-alive 3 gprs ns timer tns-alive-retries 10 gprs nsvc 0 nsvci 1800 gprs nsvc 0 local udp port 23000 gprs nsvc 0 remote udp port 23000 gprs nsvc 0 remote ip 127.0.0.1 gprs nsvc 1 nsvci 0 gprs nsvc 1 local udp port 0 gprs nsvc 1 remote udp port 0 gprs nsvc 1 remote ip 0.0.0.0 no force-combined-si trx 0 rf_locked 0 arfcn 0 nominal power 23 max_power_red 0 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 PDCH hopping enabled 0 timeslot 5 phys_chan_config PDCH hopping enabled 0 timeslot 6 phys_chan_config PDCH hopping enabled 0 timeslot 7 phys_chan_config PDCH hopping enabled 0 mncc-int default-codec tch-f fr default-codec tch-h hr nitb subscriber-create-on-demand assign-tmsi OSMO-BTS-TRX Config file ! ! OsmoBTS (0.4.0.372-f65b) configuration saved from vty !! ! log stderr logging filter all 1 logging color 0 logging print category 1 logging print extended-timestamp 1 logging level all everything logging level rsl debug logging level oml debug logging level rll notice logging level rr notice logging level meas notice logging level pag info logging level l1c debug logging level l1p info logging level dsp debug logging level pcu notice logging level ho notice logging level trx notice logging level loop notice logging level abis notice logging level rtp notice logging level sum notice logging level lglobal notice logging level llapd debug logging level linp notice logging level lmux notice logging level lmi notice logging level lmib notice logging level lsms notice logging level lctrl notice logging level lgtp notice logging level lstats notice logging level lgsup notice logging level loap notice ! 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 127.0.0.1 osmotrx fn-advance 20 osmotrx rts-advance 5 osmotrx tx-attenuation oml instance 0 bts 0 band GSM900 ipa unit-id 1800 0 oml remote-ip 127.0.0.1 rtp jitter-buffer 100 paging queue-size 200 paging lifetime 0 uplink-power-target -75 min-qual-rach 50 min-qual-norm -5 no ms-power-loop timing-advance-loop trx 0 power-ramp max-initial 23000 mdBm power-ramp step-size 2000 mdB power-ramp step-interval 1 ms-power-control dsp phy 0 instance 0 Regards

2 1

Usrp with 3G
by Snehasish Kar 01 Feb '17

01 Feb '17

Hi Can 3G be used with USRP? BR Snehasish

3 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC February 2017