Hi!
I've been experimenting for the last couple of hours with two BS-11 in
a multi-drop configuration.
The connection looks like this:
HFC-E1 connects to BTS A Y01/Y02, just like normal.
BTS-A Y03/Y04 connect to BTS-B Y01/Y02.
BTS-A LI object is configured as multi-drop
BTS-B LI object is configured normal (star)
BTA-A is configured to use TEI 25 on TS 1 for OML (normal)
BTS-B is configured to use TEI 26 on TS 10 for OML (differnt)
If I put the MA-10 A-bis signal analyzer between BTS A and BTS, I can see
* that the E1 physical layer is up and there are no alarms
* BTS-B sends TEI requests on timeslot 10, as requested
however, there is no response. Looking at TS 10 between BTS-A and BSC,
I can see that there are no TEI requests or any other data.
GSM 12.21 specifies a "CONNECT MULTI-DROP LINK" message, using which you can
map two E1 timeslots on two interfaces to each other. I've done this (mapping
port 0, TS 10 to port 1, TS 10) - but it seems the BS-11 does not support this
message. The MA-10 also calls it an "unknown message".
I'm Sending this message to object class 0xa5 (SiemensHW) and to the LI object
in that class (object instance 7, 0, 0). The BS-11 does not respond with ACK
and not with NACK. It seems it is simply ignored silently.
Does anyone have an idea how to proceed? Or does anyone have an A-bis trace
from a working multi-drop configuration?
Thanks.
--
- 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 Tue, 4 Aug 2009 10:18:55 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> Status update: I have now hard-coded a MS power limit of 20dBm (100mW) for all
> activated channels. The BS-11 still doesn't use dynamic MS power control
> yet, but that is optional anyway. At least we're sure the MS now get told to
> use no more than 100mW to talk to the BTS.
If you not already modified it, please don't forget to adjust the "Cell
Selection Parameters" in System Information 3 and 4. The GIT version
from a few days ago still sets MS-TXPWR-MAX-CCH to the maximum. This
means that the power of the initial RACH burst is too high although
the channel power gets properly adjusted later.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi again,
I'm currently in the train, so forgive me posting the initial TODO list
to the mailing list rather than the wiki.
I'll put it in the wiki soon. If you want to take on of the items, just let
me know!
What I think we have to do before HAR is as follows:
== Actual code ==
=== absolutely required ===
* finish and test the SMS implementation [Harald]
* make sure we enable MS power control and impose a global limit of
100mW for the uplink (MS->BSC) direction by means of the MS POWER IE's
and the BCCH information. That sounds like something for Dieter to
figure out, especially since he has measurement equipment ;)
* test dual-BTS-on-single-E1-card config [Harald]
** up to now, we have only tested with two nanoBTS, not BS-11 !
* test dual-TRX operation of BS-11 on OpenBSC [Stefan/Daniel, can you do that?]
** channel allocator can be tweaked to give 2nd TRX a preference for debugging
[I'll add those to trac, since they are really important]
=== optional ===
* implement a 'provisioning mode' to OpenBSC that
** acccepts every new IMSI the first time we see it
** sends a SMS with a auth token to that mobile
** disconnects that mobile immediately
* implement a web site / cgi script
** once user enters correct tuple of ISMI + auth code, we
*** assign him a number (user cannot choose, we assign)
*** set authorized=1 in the sql table
* implement a web site bug tracker for user bug reports
** the should include detailed information about the phone model,
his phone number and the exact timestamp, so we can match it in
the pcap's
* add more introspection code for the VTY interface to explore the run-time
data structures in OpenBSC
* implement different TCH assignment schemes (early / very early / OCASU)
* do we really want a SDCCH/8 or is SDCCH/4 for each BTS sufficient?
* some more testing with two BTS
* in case we call a user who is currently offline/busy, generate SMS
about missed call and store it in the SMS table
* web interface ideas
** SMS gateway where people can send SMS from the web site
*** SMS spam function for us in case we want to inform users about something
** simplistic phone book
* enhance vty interface with administrative functions such as
** ability to close arbitrary channels (i.e. terminate a call)
** ability to kick-ban a user out of the network
*** set authorized=0
*** perform authentication procedure with reject at its end
* make sure we store all the 'this phone was registerd before to MCC/MNC/LAC'
from the LOC UPD REQ data
* make sure we really store the classmark1/2/3 together with IMEI in SQL table
== Things to bring to the event ==
* spectrum analyzer [from CCCB]
* stable OCXO reference to calibrate BS-11 internal clock
** this could be done before the event, but Harald has no precision clock source
* trace mobiles / monitor mode mobiles (if anyone has some)
* some poles to which we can mount the BS-11 ?
== Misc ==
* draft 'usage terms & conditions' to be put on the registration web site
and the HAR2009 wiki, indicating
** all signalling and traffic data will be stored for R&D purpose
** we do not employ authentication and/or encryption
** we do not provide any service guarantee
** this is for evaluation+testing only
** no handover/roaming and/or external calls
** no warranty for any damage to MS, SIM, ...
** IMSI/IMEI information will not be disclosed by us, but people can sniff it
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 Johannes,
On Mon, 03 Aug 2009 22:56:08 +0200, "Johannes Schmitz" <jsemail(a)gmx.de> wrote:
>
> At this point I have got one general question, maybe also towards
> Dieter:
> How can A3/A8 be proprietary by any operator? How does international
> roaming work then if there is no standardized algorithm?
As far as I know for roaming the foreign network receives a RAND-Kc-SRES
Triple from the home network so there is no need to know A3/A8 used by
the other operator.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi, I'm a long time lurker into this project and I've wondered something for
a bit of time.Knowing that we can use an ip.access nanoBTS to work on
OpenBSC, why not adapt OpenBSC for UMA (unlicensed mobile access)
standards?
I know over here in the US we currently use UMA with T-Mobile over WiFi to
communicate back to the T-Mobile servers and eventually off to the GSM and
regular ol' networks.
http://www.umatechnology.org/specifications/index.htm is the UMA
specification, and to my knowledge T-Mobile US's @Home service uses the
1.0.3 protocol revision.
To me it seems like it'd be trivial to make a derived copy of OpenBSC with
UMA support up and running, but I'd like some other thoughts into this
matter. I'm not a programmer by any means here, so if this is impossible,
well, then so be it.
-DC
Hello Harald,
On Mon, 3 Aug 2009 12:49:40 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> I've been asking Dieter all the time to send patches that we can integrate.
> However, nothing has been coming forward yet. Especially if we look at
> nanoBTS-only and ignore the HFC-E1/BS11 stuff, it should be pretty easy,
> most likely just some different header filee includes here and there.
See my other post, basically only one function is missing. There might
be issues with the "<linux/xxx>" header files included in mISDNif.h (I
am not sure if this affects the current Cygwin version too, if yes, three
dummy empty header files are good enough). The rest can be used "out of
the box" (I had to create a "bootstrap.sh" file here, not sure how it is
done in Linux, in some other projects "bootstrap.sh" seems to be included
which runs the automake tools). Because of this I did not see any reason
to post something (it might be too trivial and till now there was no real
need).
So this is preety much straightforward, at least for anyone with Linux
experience. If you don't have any Linux experience, you have of course
learn everything related to the GNU tools (GCC and so on). Then its most
certainly easier to start with Linux, maybe with a "command-line" only
version running in a Virtual Machine (which will most certainly work
with the nanaoBTS too).
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Johannes,
On Mon, 3 Aug 2009 11:54:17 +0200, "Johannes Schmitz" <jsemail(a)gmx.de> wrote:
>
> I am thinking for some time now how this could be done. What i have seen so
> far, is that A5 is open to the public so implementing it is no problem. But
> A3/8 is secret so what is you idea of implementing it? Since it is inside
> the SIM I don't see how it could be replaced.
You might have a look here:
http://lists.gnumonks.org/pipermail/openbsc/2009-July/000584.html
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Nordin,
On Mon, 03 Aug 2009 09:50:18 +0200, "Nordin" <bouchtaoui(a)gmail.com> wrote:
>
> If Dieter has a Windows variant of OpenBSC, it would be great. For me
> now, it's still much easier to debug in windows than in Linux, because
> I'm not yet comfortable with gdb in comman-line.
Just as a clarification: I don't have a Windows variant of OpenBSC, I
just compile it with Cygwin. Beside the installation of the required
libraries (for the database) all what is needed is a minor modification
for a missing function in vty.c (Cygwin does not have it, the following
is taken from a Cygwin related posting). The Cygwin version works fine
with the nanaoBTS.
#if defined(__CYGWIN__)
/* Workaround for Cygwin, which is missing cfmakeraw */
/* Pasted from man page; added in serial.c arbitrarily */
void cfmakeraw(struct termios *termios_p)
{
termios_p->c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP|INLCR|IGNCR|ICRNL|IXON);
termios_p->c_oflag &= ~OPOST;
termios_p->c_lflag &= ~(ECHO|ECHONL|ICANON|ISIG|IEXTEN);
termios_p->c_cflag &= ~(CSIZE|PARENB);
termios_p->c_cflag |= CS8;
}
#endif /* defined(__CYGWIN__) */
For the BS-11 I have a private, experimental modification which is not
public, it requires a special Windows driver for the E1 card.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
