Hello Nordin,
On Tue, 07 Jul 2009 14:08:22 +0200, "Nordin" <bouchtaoui(a)gmail.com> wrote:
>
> I have good news now, I'm able to register to our bts manually. What I
> did is download the latest openbsc sources and compiled the whole
> project, that's it. I downloaded the project using git via port 80, I
> posted a mail about that. So I guess the GPRS in the Rest Octets have
> nothing to do, just the SIs were not complete. I'll analyze what went
> wrong with the SIs.
You don't mention which git branch you use, so its probably the
master branch. If you look at the recent changes you will notice
that the SYSTEM INFORMATION 3 and 4 rest octets are now set to the
padding bytes which means they contain no information (which also
means no GPRS). So this is the most important part where you have
to look for differences.
I can confirm that a HTC Touch Pro will not register to the BTS
if the GPRS indication is set, it will register if it is not set.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Philipp,
On Sun, 26 Jul 2009 21:43:22 +0200, "dexter" <zero-kelvin(a)gmx.de> wrote:
>
> I have no experience in those things, i never connected a sender and a
> receiver directly for measurement proposes. I am afraid to damage BTS
> and/or MS by trying the first solution.
If you want to connect the BTS and an MS directly, you have to use
an attenuator to reduce the signal to some "reasonable" level. To
give you some numbers about "reasonable": The maximum RF output level
of two different GSM tester which are intended for direct connection
to an MS are -14 dBm for one of them and -40 dBm for the other. To be
on the safe side I would make sure that the level is below -40 dBm,
this is more than enough for good receiption (poor receiption is around
-100 dBm). If the signal is too strong, you can damage the MS and/or BTS.
Please note that I have not tried to connect a BTS and an MS yet, my
experience comes from the GSM testers only.
One problem I see with this approach is how to handle the separate
RX and TX connectors of the BS-11.
> What do you think, what would you do? How do you ensure that you do not
> interfere with the with the official GSM networks? I think sometimes it
> would be very nice to make 100% sure that no HF signals leave the desktop.
I you can't make sure that no RF signal is emitted, you can at least try
to cause as little trouble as possible:
- use a GSM channel which is not used by an official network, make sure
that there is at least one free guard channel in between the channel
you use and the official channels.
- set the power level of the BTS to its minimum (0.03 Watt for the BS-11)
and set the NM_ATT_RF_MAXPOWR_R attribute to its maximum (6 for the
BS-11). For the BS-11 the RF output level should then be around 1 dBm.
- If you want to further reduce the BTS power, you can put an attenuator
between antenna and TX output.
- for the MS make sure that the power class is as low as possible when
activatig a channel.
- set the power for RACH access to a low level (in SYSTEM INFORMATION
TYPE 3 and 4).
- use an MCC and MNC which is not an official one.
- only allow a know MS to register on your network.
- To make sure that normal MSs won't be able to see your network,
you can set the cell to "barred". However you then need a special
MS to test, for example the Nokia Network Monitor allows to
set the MS in a mode which allows to access barred cells. And
with a special Test SIM it should be possible to access such
a cell with other phones too (the "cell test" operation mode
has to be enabled on the SIM).
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Harald,
On Wed, 29 Jul 2009 16:55:23 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> Great! can you please provide one FR and one EFR pcap file for Andreas
> Eversberg? It's probably best to replace the two corrupted files that I've
> attached to the nanoBTS wiki-page.
I am not sure if my two FR and EFR cpatures are good examples for the
Wiki, the call is from one person only (me) counting numbers and saying
"Hello Test" or similar things and you hear the voice on both channels
because the two phones are close to each other. Of course they are
good enough as an example for implementing the RTP media feature. So
let me know if I shall provide them to Andreas only (Andreas, shall
I send them to you as email, they are about 240 KByte as ZIP file ?).
> You do have a wiki account, I assume.
I don't think so, at least I have not yet requested an account.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Harald,
On Wed, 29 Jul 2009 15:48:32 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> I'm telling you, OpenBSC's RTP proxy works fine. I've just made another call
> and there are no drop-outs of .8 seconds or anything like that.
I am sure that the proxy is working, I never doubt that. I guess for some
reason Wireshark is just missing the data. I was joking about Windows
versus Linux performance, but maybe this was not clear enough.
> As all it uses is the sockets API, i.e. the very same calls that the
> input/ipaccess.c module already uses, I think it should be very easy to make it
> build using the posix compatibility of cygwin.
I tried it in the meantime. No problem at all. The git version works
as expected and Wireshark does not miss any packets here, each call
is about 30 seconds. I tried it with EFR and FR, Wireshark can
save the RTP payload, for EFR I had to convert the data first so
that they fit to the GSM 06.35 reference implementation (they use
a strange format which stores every bit into two bytes). For FR,
Toast can convert the payload immediately. Tested on Windows XP
and cygwin, Wireshark and bsc_hack running on the same machine.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi!
Please note:
===========================
commit d46299da00f923b24043aa37fa2bae17ffcc1ff7
make channel allocator policy multi-TRX aware
For now, we assume that TRX1 (and higher) all have a TCH/F configuration
on all of their timeslots
commit 67b4c30a9de972d199830bba5535e934bd47ac0f
complete TRX1 support for BS11
* remove old HAVE_TRX1 definition, replace it with '-1' commandline argument
* make sure we actually configure the OML TRX attributes with a different
ARFCN than TRX0
* make sure we configure timeslot 0 of TRX1 also in TCH/F mode
This code is untested, but if you have a dual-trx BS-11, and the second TRX
is activated, you should be able to run bsc_hack with the -1 option to enable
and use the second trx. It works like this:
* TRX1 shares E1 timeslot 0 for signalling
* TRX1 RSL link uses TEI2 (TRX0 uses 1)
* TRX1 on ARFCN+2, i.e. if you have TRX0 on 122, TRX1 will be 124
===========================
I'm very happy if somebody wans to test this. First of all, it is important
to see if there are any error messages during OML and RSL brigup, and if
the TEI2 link is actually established from mISDN.
If you want to actually use the second TRX, you will either have to make sure
all TCH/H on TRX0 are used (establish sufficient simultaneous calls), or
hack chan_alloc.c to give a preference to TRX1, or to do round-robin or
whatever :)
Regards,
--
- 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)
Hello Harald,
On Wed, 29 Jul 2009 14:43:12 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> If you're interested, you can certainly try for yourself with your nanoBTS...
>
You are joking, right ? How should it work on my Windows machine if it
does not work on Linux ;-) ?
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Nordin,
On Wed, 29 Jul 2009 11:51:59 +0200, "Nordin" <bouchtaoui(a)gmail.com> wrote:
>
> I can't find a good link about how several MSs on one ARFCN can send and
> receive speech data.
Have a look at the following, the first is a general introduction with
good references to the GSM specification, the second is about speech
coding:
http://en.wikipedia.org/wiki/Um_Interfacehttp://www.gsmfordummies.com/encoding/encoding.shtml
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Harald,
On Wed, 29 Jul 2009 12:33:59 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> The FR pcap file is attached to this mail. I'll also put it to the nanoBTS wiki
> page, like the EFR capture before. I hope this helps you to decode the voice
> samples.
Decoding with Toast would work fine but there is the same problem, lots
of missing packets. If I look at the capture timestamps, there seem to
miss about 0.8 seconds of data at regular intervals (the first disruption
is at packet number 681, the next at 710, 742, ...). These are also the
positions where the Wireshark RTP analysis complains about wrong sequence
numbers.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Harald,
On Tue, 28 Jul 2009 20:58:46 CEST, "Dieter Spaar" <spaar(a)mirider.augusta.de> wrote:
>
> I just took a quick look at the dump with Wireshark, its possible to
> safe the raw RTP payload from within Wireshark and it looks OK (31-byte
> EFR packages starting with 0xC in the high nibble). However I have
> no ready-made EFR decoder available so I can't decode the speech.
I did play a little bit with the EFR reference implementation from
GSM 06.35. Its possible to convert the data and I can understand a few
words (a "Yes" at the beginning and a "Bye" at the end). However it seems
that several RTP packages are missing, also the RTP Analysis Tool of
Wireshark says so (according to it more than 80% is missing). Anyway,
basically EFR decoding seems to work as expected.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
