simplify logic to check whether a BSR fits and, if so, which type.
before the check has been done in two places.
we now also accomodate for the CE subheader size.
we've not checked the return value when adding a new CE, like BSR or PHR,
for a UL MAC PDU. For very small UL grants, this could fail and
we need to remove the subheader again before packing the PDU.
This fixes issue #1649.
before the BSR was extracted but the actual index (between 0 and 63)
was not stored but directly converted into bytes.
for log parsing and debugging it is easier to follow the index
value. this patch therefore adds both values to the log message
and extends the API accordingly.
all calls that manipulate the RLC and/or PDCP arrays suffer
from a high deadlock risk if a PHY worker holds the RLC
AM Rx mutex at the same time when the stack wants to carry
out this reconfiguration.
this applies to RRC Reconfigs, but potentially also to RRC Connection
Reestablishment or even RRC Connection Setup, although this should
seldom be the case.
By breaking the call stack between RLC->PDCP->RRC->RCL and
carrying out the reconfig as a single task without holding the
RLC readlock the deadlock should not happen anymore.
This should fix issue #1593
- Import the srslog project into srslte.
- Ported srsue app to use the new logging framework.
- Implemented a wrapper that dispatches log entries to srslog.
- Renamed an existing log test to be more specific to avoid name clashes.
the PSS detection needs more temporary buffer than a full subframe.
we therefore need to allocate and initialize the sync object with
larger maximum size to support Scell search of large cells, e.g.
20 MHz
this fixes issue #1538
* add locked and unlocked version of has_data() since one is
called from stack and one from PHY threads
* add comments in each interface section as to why locking
is required or not
* remove RLC rwlock when not required
* move calls only used by RRC to RRC section
as 3400 or 2.685 GHz is on the edge of band 7, some phones won't connect
to a 20 MHz cell on this EARFCN.
In order to simplify testing with other bandwidths we change the default EARFCN.
this patch refactors the SDU queuing and dropping policy of the RLC and PDCP layer.
the previous design had issues when packets have been generated at a higher
rate above the PDCP than they could be consumed below the RLC.
When the RLC SDU queues were full, we allowed two policies, one to block on the write
and the other to drop the SDU. Both options are not ideal because they either
lead to a blocking stack thread or to lost PDCP PDUs.
To avoid this, this patch makes the following changes:
* PDCP monitors RLC's SDU queue and drops packets on its north-bound SAP if queues are full
* a new method sdu_queue_is_full() has been added to the RLC interface for PDCP
* remove blocking write from pdcp and rlc write_sdu() interface
* all writes into queues need to be non-blocking
* if Tx queues are overflowing, SDUs are dropped above PDCP, not RLC
* log warning if RLC still needs to drop SDUs
* this case should be avoided with the monitoring mechanism
reducing the sync queue len to 1 caused an issue when the
PHY was locking the mutex while trying to push a TTI event
on the stack.
instead of signaling the new TTI within the PHY, we now do it outside
in the DUT (after releasing the PHY mutex)
apply same change that we've done on the eNB also on the UE
to avoid the PHY processing TTIs faster than the stack.
Without that, we see lots of those in the logs:
...
08:39:17.580325 [STCK] [W] Detected slow task processing (sync_queue_len=7).
...
before entering RRC idle, after receiving a RRC connection release for example,
we need to wait until the RLC for SRB1 or SRB2 have been flushed, i.e.
the RLC has acknowledged the reception of the message.
Previously we have only waited for SRB1 but the message can also be received on SRB2
and in this case both bearers need to be checked.
The method is now streamlined to check both SRBs and is also used when
checking the msg transmission of an detach request.
unfortunately, the rapidjson version shipped with Ubuntu 16.04
doesn't support the GetArray() API so we need to use
normal iterator to loop over the array
* Added the appropriate code for handling and sending the
re-establishment procedure messages to rrc_ue.c/.h.
* Triggered RRC reconfiguration after the reception of RRC
re-establishment complete
* Refreshed K_eNB at the reception of re-establishment
request
* Changed the mapping of TEIDs to RNTIs in the GTP-U layer,
as the RNTI might change with reestablishment.
Bugfix the wrong ra_rnti calculation in ra_proc::state_pdcch_setup.
According to TS 36.321 Subsection 5.1.4 Random Access Response reception, we can see the formula on RA-RNTI, which is,
RA-RNTI= 1 + t_id + 10*f_id,
where t_id is the index of the first subframe of the specified PRACH (0≤ t_id <10), and f_id is the index of the specified PRACH within that subframe, in ascending order of frequency domain (0≤ f_id< 6). Then, reading the srslte source code, we can see that, the code should bugfix.
BTW, the wrong code can run normal for LTE_FDD, causing of the info_f_id = 0; but it should be wrong, when it is LTE_TDD.
if no cell/PLMN can be found if the UE is switched on, the UE was never
trying again.
In theory this would be handled by T3410, but the timer
is not started in case the PLMN search isn't done yet.
The current TTI gap calculation assumes strict continuity
of radio time stamps, even when retuning, changing sample rate, etc.
This is certainly desireble but not necessaritly the case and may cause
issues when negative time gaps or too large gaps are detected and reported
to the stack.
this patch makes the assumption that valid TTI jumps are between 1ms
and 1s and that larger gaps are the result of screwed time-stamps
or too long radio operations.
the examples are commented but by just uncommenting those
two lines the user should be able to run a eNB and UE on the same
machine in SISO mode over ZMQ
extend GW-NAS interface to signal test mode activation.
The method is a noop in the normal GW but is implemented in
the TTCN3 DUT according to TS 36.509 for Mode B
This commit implements support for the CLOSE_UE_TEST_LOOP message.
Currently the mode is not saved and looping the data is not implemented.
Only the *_COMPLETE message is sent back as a response.
First of all, with this the NAS conformance tests pass with ciphering and
integrity turned on. Before only integrity was working.
Mainly the NAS was applying the integrity protection and/or ciphering
incorrectly because it wasn't taking the secuirty status of the PDUs
into account. Some where already correct, some not. The patch
streamlines the handling for all outgoing messages.
during deinit of the UE/eNB it could happen that the log_ptr
was already set to null but the stack thread was still accessing
it through log_h->info()
i've moved the old macro into a new header and used as as much
as possible. there are still places in the code where similar
macros are used but we would need to change the variable name
to replace them
previously the NAS would cancel a attach request procedure if the PLMN
is already selected. PLMN selection, however, in not necessarily happening
before requesting RRC to establish a connection.
this is to better differentiate from "send_attach_request" that
only packs and send the actual attach request message. The
entire attach procedure may include PLMN search, etc.
t3402, t3410 and t3411 are now managed in the sender
function of the attach request. previosly they were only
correctly started in the high-level NAS call start_attach_request()
which may not be called if NAS itself resends the request
* Use task id to track old background tasks in RA procedure
* Improve robustness against RF overflow in PHY
* Increase SNR out-of-sync threshold
* Do not change frequency if it's the same
* Increase sync priority
* Increase time to start receiving to reduce input buffer occupation
* Use scoped lock in sf_worker
- move handling to NAS
- use switch off to enable airplane mode (don't wait for EPC response)
- add tiny FSM to control airplane mode activation/deactivation
- only start on/off counter after state has been entered
the signal handler is the same for all three apps. The "running" flag
as well as the file_logger object are in the common header in order
to allow the signal handler to flush the file if the alarm goes off.
The test TC_9_2_1_1_1 sends a Cell->AddOrReconfigure->Basic message
without a "StaticCellInfo" member. This is used to change SIB1 of
the cell and simulate a different PLMN/TAC in the test.
handle_request_cell_basic() ignored the json message if "StaticCellInfo"
is missing which results in the SIB not being updated (PLMN stays as
00102 for example).
With this patch the SIBs after the json are now parsed even if there
"StaticCellInfo" is missing. A confirmation of the json is not sent
because the test does not seem to expect one in that case.
Related: TC_9_2_1_1_1
previously PDCP security (integrity and ciphering) could only
be enabled for both Rx and Tx at the same time.
this, however, caused an issue during the conformance testing in which,
in TC_8_2_1_1() for example, the eNB sends a SecModeCommand and a
RRC Reconfiguration in the same MAC TB. In this case, the eNB
needs to be able to enable DL security right after sending the SecModeCmd
in order to send the RRCReconfig encrypted. However, enabling UL security needs
to be postponed until after the SecModeComplete is received.
This patch allows to enable PDCP security for rx/tx independently if
that is needed. The default way is like before, enabling it for tx/rx at
the same time.
this fixes an issue where commands are received out of
order and we are therefore applying configs incorrectly. if
commands include a timinginfo we are now putting the command
on a queue that the SS reads after the start of a new TTI.
the security and cell reconfig commands will be added in another
PR after the AS_security command has been fixed.
this fixes an issue in the step() function of the connection_request_proc
in which the dedicated_info_nas message was passed to RRC without
checking if its actually valid or not, i.e. contains a message at all.
because this check was missing and the step() function could be called
multiple-times, the function would overwrite the dedicated_info_nas
in RRC, and therefore causing the connection setup complete to fail
this fixes a bug in which the contention resolution timer expired
and the RA proc entered the BACKOFF state.
In the same TTI, a MAC PDU with the contention reslution ID is received
and the already aborted RA procedure succeeds. Unfortunatly with the
wront c-rnti which has already been reset before. See log excerpt
below:
16:16:36.909687 [RRC ] [D] MEAS: Processing measurement of 1 cells
16:16:36.909706 [RRC ] [I] MEAS: New measurement serving cell: rsrp=-85.00 dBm.
16:16:36.909732 [MAC ] [I] [ 6283] RA: ConRes: Contention Resolution Timer expired. Stopping PDCCH Search and going to Response Error
16:16:36.909749 [MAC ] [D] [ 6283] RA: ConRes: Backoff wait interval 143
16:16:36.909771 [MAC ] [D] [ 6282] Delivering PDU=27 bytes to Dissassemble and Demux unit (Temporal C-RNTI)
16:16:36.909799 [MAC ] [D] [ 6283] Found Contention Resolution ID CE
16:16:36.909814 [MAC ] [D] [ 6283] RA: Backof: MAC PDU Contains Contention Resolution ID CE
16:16:36.909826 [MAC ] [D] [ 6283] Msg3 buffer flushed
16:16:36.909858 [MAC ] [I] [ 6283] RA: Backof: Random Access Complete. c-rnti=0x0, ta=0
16:16:36.909871 [MAC ] [D] [ 6283] Saved MAC PDU with Temporal C-RNTI in buffer