Hello Eric,
On Fri, 17 Jul 2009 17:52:17 +0200, "Eric Cathelinaud" <e.cathelinaud(a)googlemail.com> wrote:
>
> If nothing possible I will try to deal with the 470ms period.
> Can you tell me if the mobile will RACH at each paging request or if it can
> miss some?
If the MS receives a paging request for itself and is allowed to access
the network, than it will start the immediate assign procedure (The details
are in GSM 04.08, a good overview with reference to the specification is at
http://en.wikipedia.org/wiki/Um_Interface, many thanks to David Burgess for
writing it down). The MS will not react on further paging request as long as
the immediate assign procedure is running.
> I already saw in OpenBSC that the paging request is sometimes send more than
> once for a call so I am not sure. May be it could be something to fixe in
> the code? Or the phone sometimes doesn't react as it should?
The BSC can't be sure that a single paging request is received by the
MS so it (optionally) has to repeat it (there can be distortions, weak
signal and so on).
> Normally the RACH is sent 3 time slots after the paging request right?
I don't think so, the RACH is always on TS0 of the uplink (at least this
is how I understand it) and the PCH is not necessarily on TS0 (depending
on the configuration). The reaction of the MS surley depends on the
firmware/hardware of the phone and how fast it works, so you don't
have a fixed delay. The MS usually has enough time to react, the
T3113 timer defines how long to wait for a PAGING RESPONSE and than
optionally repeat the paging request (if and how often the paging
request is repeated, is not defined in the specification). I don't
have exact numbers for the T3113 timer because its up to network,
but common values seems to be around 5 seconds.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Eric,
On Thu, 23 Jul 2009 11:35:33 +0200, "Eric Cathelinaud" <e.cathelinaud(a)googlemail.com> wrote:
>
> I would like to ask another question. I can see on which time slot the burst
> is sent but i can't see the frame and the multiframe number. Is it available
> somewhere?
Not in the Abis communication, its the BTS which cares about frames
but not the BSC. For the nanoBTS it is most certainly possible to get
debug traces from the debug port (but probably not on Abis) which
contain the frame number, but I am not aware that the same is possible
for the BS-11.
If you are interested in this low-level Layer 1 stuff, you might have
a look at OpenBTS, you can adjust nearly everything or trace at a really
low level.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi folks, I hope this finds you all in the best of health. As a start, I have read some basic GSM articles and went through bsc_hack.c. Few questions are bugging me and I would appreciate some info regarding them:
(1) With which type(s) of BTS does OpenBSC work?
(2) What is OML NM?
(3) What is the best way to follow the path in the code in case of a call?
Thanks.
_________________________________________________________________
Show them the way! Add maps and directions to your party invites.
http://www.microsoft.com/windows/windowslive/products/events.aspx
Hello Nordin,
On Mon, 27 Jul 2009 14:11:56 +0200, "Nordin" <bouchtaoui(a)gmail.com> wrote:
>
> I downloaded the latest developer's Wireshark 1.1.3, with no result. I
> know it's easy asking for an Abis-parser, but I thought there was a
> patch for it.
If you take one of the latest daily automated Wireshark builds it
will work, even on Windows. No need to compile the sources if
you don't want to. I use "1.3.0-SVN-29061" and it contains Harald's
patch for the nanoBTS.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi,
I am trying to deal with wireshark to understand what happening in each
function in the code.
It says that the file seems to be corrupted:
"The capture files appears to be damaged or corrupted. (libpcap: LAPD file
has a 15-byte packet, too small to have even a LAPD pseudo-header)"
Is it a problem?
I still can read the Abis communication.
I saw that some rsl packets are malformed. Is it coming from a missing
implementation in the code that need to be fixed?
Thanks
Eric
>On Thu, Jul 23, 2009 at 12:26:14AM +0200, Harald Welte wrote:
>> Hi again,
>>
>> I'm currently in the train, so forgive me posting the initial TODO
list
>> to the mailing list rather than the wiki.
>
>this is now at http://bs11-abis.gnumonks.org/trac/wiki/HAR2009
Check out Eventphone. They run DECT network. Why not linking to their
network? I am not at HAR, but I can help setting it up. An extra E1 card
is required to link to Eventphone's machine...
http://www.eventphone.de/guru/?language=de
Hi!
So for everyone who has problems with BS-11 clock accuracy,
what would be the theoretical straight-forward way to solve the
problem, is to replace the 32.768MHz crystal oscillator on the E1
card with a OCXO of the same frequency.
So what we're looking for is an OCXO with +/- 0.05ppm or higher stability for
3.3V power supply. Unfortunately I was not able to find one at that
frequency, even digikey doesn't have one.
If anyone can find a source for a OCXO in the abovementioned
parameter range (and small quantities), I think quite a number of people would
be interested in buying one and connecting it to their E1 boards. Any help
is much appreciated.
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)
Hi!
For finishing proper SMS support, I need supoprt for transactions. Similar
to Call Control, SMS can also have a number of different transactions
active of any time.
Before my changes, the transactions were tied to call control, which is
obviously not good if that code is to be reused from SMS.
Also, the transaction was linked to the gsm_network as well as the gsm_lchan.
I think both are somehow wrong.
Why are they not a property of the network? Because a transaction always
belongs to a 'MM entity' (gsm spec language), or a gsm_subscriber in openbsc
terminology. That subscriber then is part of a gsm_network.
And why are they not part of a gsm_lchan? Because a transaction can be
initiated on one lchan and then move to another lchan, e.g. in case a SMS is
sent just before a call is made, where we start on an SDCCH and might continue
on a SACCH. I will keep the lchan pointer in the meaning of 'current lchan
through which we transmit messages to the remote MM entity'.
Tying the transaction to the subscriber neatly addresses both of those
issues.
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)
Hi everyone, I am new to OpenBSC and I think the best way to contribute to it is to get to know the source code first. I would appreciate any help regarding how to begin understanding the source code. And what are the main features of the code? What is the best approach to start learning OpenBSC. And is there any good material on OpenBSC.?
Thanks.
_________________________________________________________________
Share your memories online with anyone you want.
http://www.microsoft.com/middleeast/windows/windowslive/products/photos-sha…
Hello Harald,
On Wed, 22 Jul 2009 23:49:00 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> Even with two BTS at two TRX (exercising all our four ARFCN), the total call
> capacity is not more than 13 simultanesous MS-to-MS calls (since each call
> requires two timeslots). Yes we could do half-rate, but we have no software
> support for that so far.
You have the adjacent channels 121 to 124 for GSM 900 ? As far as I am
aware, adjacent channels will disturb each other. From what I know,
real networks usually have one free guard channel in between. So at
least the configuration of using adjacent channels should be checked
in advance (but you don't know how well different phones behave).
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
