Only the known BA (band allocation) is used to check for the cell to camp
on. If there is no BA or if nothing is found, the process triggers normal
cell selection.
After location update (for example), the mobile switches to the strongest
cell in the current band allocation.
Pressing CTRL+c causes the detach process to run, then the mobile exits.
This procedure only runs after attachment (location update) and if detach
is required.
The SABM with the detach message is confirmed by a DISC message. the BS11
says that this is caused by sequence error or N200+1 error. Maybe someone
can trace that.
While testing, you may find out that making an emergency call is rejected
with cause 5 (illegal ME), because emergency facilities in some countries
like to reject calls without knowing the subscriber.
An emergency IMSI can be defined via VTY, so it is possible to make calls
with that IMSI, even without the SIM, because authentication is not
applicable during emergency call establishment.
All the information above, I received from the freely available 3GPP TS 04.08.
See NOTE at sub clause 4.5.1.5.
Now location update reject works. The rejected network/cell is stored in
an appropriate list. The lists can be dumped from the VTY.
A fake authentication response is generated until the SIM interface is
available. If the network rejects the test SIM, due to authentication
failure, it is removed and limited service state is entered. This currenlty
works on networks with SDCCH on the TS0 only.
In case of registration not possible / requried, the appropriate result
message (REG_FAILED / REG_SUCCESS) must be returned to PLMN process.
Location updating message fix.
The "BA range" is used for cell re-selection.
Due to layer 1 issues, the process gets stuck very often or looses
synchronization.
After location update, I can now make a call via VTY on SDCCH:
Call control sends SETUP request after requesting an MM connection.
My phone on the network side rang!! Call control fails and requires
further debugging...
The location update is now performed after the channel is assigned.
In dedicated mode the network receives the LOCATION UPDATING REQUEST.
The reply (IDENTITY REQUEST and LOCATION UPDATING REJECT) is received.
But subsequent message like the IDENTITY RESPONSE is not transmitted
by lapdm.c.
I hope that it fixes the crash issues. If a sysinfo was received when no cell is
selected, it was written to a NULL-pointer.
Also after selecting a cell (dedicated mode), it was not good to "continue"
an already stopped search process, if the sync fails.
liblayer23. Other applications using liblayer23 don't need to re-implement it.
Messages from layer 1 are not freed in layer2_read() anymore. They will be
freed by the upper layers. The layers may also decide to queue or to forward
the messages. In general: A message is always discarded by the message handler
and not after calling the message handler.
* port 'mobile' application to new l1ctl_tx_fbsb_req()
* make sure we have a proper downlinke header in front of l1ctl_fbsb_resp
* remove duplicate band_arfcn member of struct l1ctl_fbsb_resp
* reset the AFC to its default value when starting new FBSB task
* remove bogus l1s.sb.{synced.count} variables
* allocate msg and send l1ctl_fbsb_resp() only from process context, not FIQ
* properly report SNR and BSIC in fbsb_resp
* introduce arbitrary SNR thresholds for FB0->FB1 and FB1->SB switching
We really want to have those two as distinct operations - and we
want proper state machines in L1 to quickly return if they've
managed to acquire a FB or SB or not. Otherwise scanning will
take ages...
This code now introduces a new l1ctl_fbsb_req that is sent via
L1CTL to ask for a bitmask of FB0/FB1/SB operations. The actual
FB0/FB1 detection now no longer runs for 500 TDMA interrupts
but completes as soon as we either know there is no FCCH,
or that our frequency error is smaller than a caller-specified
threshold.
FB0/FB1 are already working, SB is not yet, sorry.
Andreas.Eversberg
Harald Welte