Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I67cb04cfacdc4f2efa8bd829ecf66f0040bf430a
|
|
* Flag to enter dedicated mode with TX disabled
* Flag to use sync info of neighbor cell
* Flag to use sync info of previous serving cell
* Index of neighbor cell
All these parameters are required to handover to a new channel.
Change-Id: Iadbc47f006d1f8a019822aedee180814de13cb2d
|
|
Change-Id: I792b52d9bf115a2def9720eed3d62982d8cdbe00
|
|
According to 3GPP TS 04.60, section 11.2.5a, the extended (11-bit)
Access Burst on RACH/PRACH is used by the MS to indicate its EGPRS
capability. One of the alternative synch. sequences (see 3GPP TS
05.02, TS1 and TS2) shall be used.
Change-Id: Iae0267a31b3314c990eb41acb2f570ca3219021c
|
|
Unlike the DATA messages, traffic frames may have different length.
Instead of having fixed payload (i.e. TCH frame) length, let's
introduce a flexible array member. This would allow one to
calculate the frame length using the MSGB API.
Change-Id: I119fa36c84e95c3003d57c19e25f8146ed45c3c6
|
|
According to GSM TS 05.02, there are two ways to enable CBCH:
a) replace sub-slot number 2 of CCCH+SDCCH/4 (comb. V),
b) replace sub-slot number 2 of SDCCH/8 (comb. VII).
Unlike SDCCH/8 (case b), CCCH+SDCCH/4 can be allocated on TS0
only, and shall not use frequency hopping. This means that
implementing CBCH support on SDCCH/8 would require much more
efforts than on combined CCCH+SDCCH/4, as in last case CBCH
messages can be received without the need to switch from
idle to dedicated mode.
This change introduces a new ccch_mode item, which should be
used by the higher layers to indicate presence of CBCH channel
on C0/TS0, so the PHY would enable decoding of CBCH messages
on CCCH+SDCCH/4 (case a) in idle mode.
Regarding to CBCH on SDCCH/8 (case b), it makes sense to
extend the 'l1ctl_dm_est_req', so it would be handled in
dedicated mode on request from the higher layers.
Change-Id: Ia94ebf22a2ec439dfe1f31d703b832ae57b48ef2
|
|
Previously, the L1CTL_CRYPTO_REQ message contained only a ciphering
algorithm and actual Kc key to be used. The key length was
calculated manually using the MSGB API.
Let's avoid manual calculations here, as it may cause unexpected
behavior if the message structure is changed. Also, let's fill
the UL header with minimal information about a channel, which
is going to be encrypted.
Change-Id: I5fab079907c5276322d3ec2b46cab81f10c7ed09
|
|
One burst indication message carries a single raw burst, forwarded
to the higher layers from DSP. The burst bits are hard-bits (0 or 1)
coming from demodulator, packed to 14.5 bytes. This is why we call
them 'raw' - no bit correction nor deciphering is performed.
Related: OS#1672
Change-Id: I75e33c38accdf2a0af961c89836c5e7a3a056bda
|
|
we add a new STATE_TBF to vthe MS model and add some L1CTL primitives
to configure that TBF mode as well as to enqueue transmissions for
blocks at a given USF+TS.
Change-Id: Ie6f37090bd45f463aa25d9e00bc06f563be5264a
|
|
As Dieter points out, this drastically improves the resiliance to high
receive levels on the C155. We cannot blindly assume a received signal
level of -85 dBm if the BTS is 2m away and we actually receive -40 dBm.
This patch extends the L1CTL_FBSB_REQ data structure in layer 1 with the
respective field, as well as the l1ctl_tx_fbsb_req() API function called
from the various layer23 apps.
"mobile" and "bcch_scan" already did a PM request and thus know the
expected signal power. "ccch_scan" and "cbch_sniff" apparently don't
do, so the -85 dBm constant is now hardcoded into the host-side source
code there, and should probably be fixed in a follow-up patch.
|
|
5 measurements are now performed during a 51 multiframe. They are performed
at one of the 5 FCCH.
Additionally a timeslot offset can be given for each measurement. This way
it is possible to measure each timeslot seperately. The given ARFCN must be in
sync with the serving cell.
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Also adapt packet creation length in L1
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
|
|
Written-by: Andreas Eversberg <jolly@eversberg.eu>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
|
|
The SIM client is now complete. Because it usefull for multiple
applications, i moved it to the layer23/src/common directory.
The SIM reader works together with mobile process. Fixes were made.
Thanx to all for testing, finding bugs, and making it work as it is
supposed to do.
The current version uses special L1CTL messages to send and receive APDUs.
This will change in the future, when BTSAP interface is completed.
Please note that this client will not work until the layer1 SIM reader
fixes and extensions are committed.
|
|
The layer23 will now set crypto mode and key when CIPHERING MODE COMMAND is
received. After crypto mode has been set, CIPHERING MODE COMPLETE is sent.
NOTE: Layer1 implements only the interface, there is no functionality to it
yet.
|
|
This is only the header, so there is no functionality yet. The
functionality for layer1 works, but it is not yet ready for commit.
This commit is required for radio ressource protocol commited later.
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
The interface between l1 and upper layer is called by several
name. IMHO l1ctl is shorted and sounds good so try to unify
using that.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|