Hi all,
I've been working on the SGSN code again for two days, and there is quite
a bit of progress, even if it doesn't really make much difference in
what you can do.
I'm still working on the signalling plane, an we still cannot send/receive
user plane packets (the actual TCP/IP).
However, a number of bugs / misunderstandings have been fixed:
1) When we send BSSGP Downlink-Unitdata, we have to always include the IMSI
of the target phone, as well as the "MS Radio Access Capabilities" IE.
This is apparently needed for the BTS to know when and how it can schedule
packets to be sent on the radio interface. However, I personally think
it's an ugly layering violation. All this information is part of the
"GMM State" in the SGSN, i.e. higher than layer3. It now needs to be
passed through LLC down into BSSGP, where it is used :(
2) LLC UI Frames have sequence numbers that need to be incremented with
every frame.
3) Some phones apparently don't like it if they don't get a P-TMSI allocated
during GPRS ATTACH and ROUTEING AREA UPDATE. According to the spec,
it's optional and I thought I could skip that feature to make things
easier initially.
4) There are two levels of C/R (Command/Response) bits, one at the LLC and
the other at the BSSGP layer. The LLC bit is now set correctly, but the
BSSGP C/R packet seems to be set even wrong by the BTS. However, I'm
now simulating the behaviour of exissting Gb protocol traces
5) The 04.08 GMM timers T3350 and T3370 have been implemented properly,
including re-transmissions of the according MM frames
6) As part of P-TMSI Reallocation, there are time windows when the SGSN
has to consider both the old and the newly allocated P-TMSI are valid
simultaneously
Finally, I've found one other bug that I'm about to fix now: When we assign a
new P-TMSI, this implicitly means that the TLLI will change, too. Since the
TLLI changes, the LLC protocol created a new "LL Entity" data structure and
re-started the sequence number at 0, resulting in all messages being dropped
in the phone until the sequence number is higher than the previous one.
I have some hope that this is the last bug before I can see packets on the data
plane coming out the TUN device on OpenGGSN.
After that, there are still the following major TODOs:
* actually check the HLR rather than accepting every IMSI
* implement BSSGP flow control for BVC and MS level
* implement SNDCP fragmentation/reassembly
Followed by more optional features, such as
* implement SNDCP header compression
* implement SNDCP payload compression
* implement LLC re-transmissions
* implement GEA3 encryption
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)
Dear Sylvaion,
I've tried my best to forward-port your 'sylvain/encryption' branch to current
OpenBSC, and you can find the result in laforge/encryption.
I haven't yet had time to test it, but I wouldn't be surprised to see something
break, considering that your code predated the introduction of
'gsm_subscriber_connection'.
Unfortunately merging the branch to master is also not really an option right
now, as it is likely to cause trouble with the BSC/MSC split, as we will
have to align our encryption support with how the A-Interface between BSC
and MSC handles things.
Nonetheless, I really would like to see this feature move ahead. There
is definitely a demand for it in the research community.
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)
Well guys,
Just being curious, are there any plans for UMTS support?
I remember Harald said something about an ASN.1 PER was an obstacle to
start for UMTS support.
Are there also nanoBTS for UMTS, I only know of 2G devices...
It was just quite on the list :p
Greetz,
Nordin :-)
Hi guys,
wow, finally found this project/list :).
First a bit of background: working at Fraunhofer FOKUS, in Berlin;
"maintaining" openimscore.org (when I still find the time); working on
openepc.net; currently doing some prototypes for the LTE access part -
MME/HSS/eNodeB - only Layer 3 and up.
What brings me here is that I have a need for getting a test-bed setup as
complete as possible, without black-boxes.The ultimate dream is to have
everything from radio to application layers running on COTS hardware for
test-bed purposes (nothing commercial).
Obviously I am coming from the upper layers to the lower ones, as we had to
satisfy first the Application Server guys. So far we've done prototypes for
P/I/S-CSCF, HSS(Cx,Sh) and some light MGCF, BGCF/etc with the OpenIMSCore.
With OpenEPC we are adding some PDN-Gw, ANGw(SGw/ePDG), PCRF, PCEF, BBERF,
ANDSF, HSS (Sp) and working on the afore-mentioned MME, HSS(S6a,etc),
eNodeB. Of course, all are prototypes, but we try to make them as
inter-operable as economically feasible.
Now I am also very interested in UMTS. We're demo-ing EPS hand-overs and the
sort between WiFi, LTE (just using it as an air bridge for now) and 3G, but
we use commercial 3G, which is quite frustrating as it seems to have a
directly proportional probability to fail with the number of phones present
in the demo room.
However, I do have an Oyster 3G femto from ip.access and would very much
like to explore on how can I use it in an environment completely under
control. I know about other BTS alternatives, but I really just need the PS
part and I need good data-rates. (CS is out of scope for me as it's supposed
to be phased out at a point and we have already the all-IP stuff on top,
even like 3GPP likes to see it)
I see that I am not the only one interested. Now I am still trying to get
some more documentation from ip.access. If any of you already figured out
how to do the basic operations or at least what is required, I would really
appreciate the pointers.
Then regarding the HLR - it seems that you have some troubles with it. Well,
we have done a couple of HSSs in the past 5 or so years, which is supposed
to be an HLR evolution suitable for all-IP environments. So we have all the
irrelevant, but required, DB back-end, provisioning interfaces or AKA
authentication sorted. Unfortunately it only has support for Diameter, with
RADIUS on the road-map due to integration with non-3GPP trusted access
networks (WPA with EAP-SIM/EAP-AKA). Also these days I am trying to add
support for LTE network attachments through the S6a Diameter interface.
If you can provide me with some quick requirements to what you need for the
HLR, I hope that we could help.
Cheers,
-Dragos
Sorry for the intrusion but I thought maybe someone here would be
interested. I have two ipaccess bts 165au to sell. Both are fully working
with POE. I'm also including the ipaccess software and manuals. Software:
BTS installer, BTS Manager, IPaccess BSC which runs on redhat(all rpm
files). Also have an msc which runs on windows but you'll need a license and
dongle to make it work or defeat the dongle. Documentations are PDFs. You
can pick it up in London or can ship it.
pics: http://tinypic.com/3ia3muxg
Hi ,
I have same problem with Luca. I could not attach my phone (Nokia N79) to
the network unless I close and re-open my phone. When authorized=0 I could
not see any location update reject log related my phone on the screen.
Changing reject cause was helpful for some other phones but It did not work
for N79. I have seen a error message on the bsc_hack screen I think that
this can be related to the problem:
<0000> abis_rsl.c:1237 (bts=0,trx=0,ts=0,ss=0) ERROR INDICATION cause=Timer
T200 expired (N200+1) times
Please help. Thanks.
Jason.
Hi, all!
If I try to change to my Test-Network with my mobile phone (not known
from network and not yet authorized!!) I can't change (of course).
Then I authorize my phone and I try again.
It does not work. I have to turn off and on my phone in order to change
to the network.
I got the information that I can solve this problem by changing the
reject cause (location updating reject cause).
Unfortunately I don't know any cause that say the phone "OK, try again
later", so that my phone will try again later.
Can someone help me and say me a code? I have to give a numeric code,
but I don't know any. It was suggested to send a "network failure" or
"congestion" or "overload", but I don't know the code for these cause...
Thanks for your help!
--
_______________________________________________________________________
Luca Bertoncello
Entwicklung Mail: bertoncello(a)netzing.de
NETZING Solutions AG Tel.: 0351/41381 - 0
Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12
HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de
_______________________________________________________________________
Hi all!
One of the issues I want to adress in the coming weeks is the HLR.
At the moment, we don't have an HLR in the traditional GSM sense. We
have something that corresponds to the same function, but without all of
the usual interfaces. This is not a problem in itself, as we do not intend
to interwork the internal-MSC of the OpenBSC with a traditional HLR at this
point.
The current implemnetation just synchronously calls subscriber_get(), which
does a database lookup. It expects this lookup to succeed synchronously,
which is only true as long as nobody else is accessing the hlr.sqlite3
database simultaneously. This is problem 'A'. Simultaneous accesses to
the database could either be manual updates, or the 'hlrsync.pl' script,
or some other kind of user interface to the database.
The problem gets worse if we now start to have a SGSN. The SGSN currently
does not access hlr.sqlite3. But if I start to implement it, we will have
concurrent accesses from bsc_hack and osmo-sgsn to the sqlite3 database,
which means that problem 'A' will become worse.
So what needs to be done:
1) Accesses like subscriber_get() need to become asynchronous, i.e.
at the time we search for a subscriber we simply issue a call and
do some state transition. Once the database process is finished
retrieving the subscriber data, we can continue the operation.
2) Introduce an actual message-based protocol between the HLR database
process and the OpenBSC and OsmoSGSN software.
Both of those fit together quite nicely. And rather than inventing our
own protocol, we should directly use the GSM MAP (09.02) messages intended for
the respective operations. That might sound complex, but we can leave out
the other parts of SS7 (MTP, SCCP, TCAP) for now. But if we already start to
encode the information elements and messages themselves according to MAP,
we would have a very clear migration path towards
* turning our HLR into something that can interoperate with real GSM networks
* allowing our Layer3/MSC code in OpenBSC to use a real GSM HLR
The MAP asn.1 code can be processed quite nicely by asn1c, thus it should be
possible to integrate with our C code quite nicely.
I'm right now studying TCAP and how it is being used by MAP in order to
determine if (and how much of) TCAP we would need. After that is finished,
I'll likely start working on a minimal HLR process (using the sqlite3 database
backend) and then convert the OpenBSC code to asynchonous MAP-based subscriber
lookups.
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)
Hi, List!
I'm new to OpenBSC, and I'm experimenting some configuration of the
program.
Now I have to try to change the power of the BaseStation, so that I can
set how far mobile phones can catch the signal of my BaseStation.
I thought, I can change the values of "ms max power" or "nominal
power", but I don't see any difference.
Is it possible to do what I try? If yes, how?
Thanks for any help!
--
_______________________________________________________________________
Luca Bertoncello
Entwicklung Mail: bertoncello(a)netzing.de
NETZING Solutions AG Tel.: 0351/41381 - 0
Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12
HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de
_______________________________________________________________________
Hi zecke,
one of the things that I've been thinking about earlier today while talking
with Roch was the fact that we do the A-bis OML overlapping / asynchronously,
i.e. if we send a 'set attribute ...' or 'opstart' message, we never wait
for the acknowledgement before sending the next message.
While this might be efficient and compliant with the specification, it is
likely to expose bugs like race conditions in software that has never been
tested against it.
So one of the ideas would be to make the abis_nm.c layer queue up messages
during abis_nm_sendmsg() and determine based on the messagetype if it is
a message that we're expecting an ACK/NACK as response. If yes, delay
transmission of further enqueued OML messages until such ACK/NACK is
received. Of course, there probably should also be a timer whose expiration
should generate at least a log file entry (and after which we continue with
the next message from the queue)
I'm not sure if you feel in the mood for implementing something like this
or not. I can also stop with GPRS work and have a look at it.
This request/response tracking would probably also be useful once we extend
our ability to send OML messages from e.g. external applications. We could
then notice who submitted the message and deliver the result back to the
caller without having to consider re-ordering or something like that.
Regards,
Harlad
--
- 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)
