RRCTL is a simple protocol (inspired by Osmocom's L1CTL) that allows
an external NAS entity to control the RRC layer of srsUE. The most
notable primitives are PLMN search, selection, and PDU transfer.
The protocol assumes traditional master-slave communication, where
one side (an external NAS entity) initiates various processes,
while the other (srsUE) executes them and indicates the outcome.
Each RRCTL message starts with a header that can be defined as follows:
+-------------------------------+--------------------------+
| Message type | 6 bits |
+-------------------------------+--------------------------+
| Message sub-type | 2 bits |
+-------------------------------+--------------------------+
| Spare (RFU) | 8 bits |
+-------------------------------+--------------------------+
| Payload length | 2 octets (big endian) |
+-------------------------------+--------------------------+
| Payload (optional) | (see payload length) |
+-------------------------------+--------------------------+
The following message types are defined at the moment:
- RRCTL_RESET - reset internal state of the external NAS interface
(does nothing for now, may be useful in the future);
- RRCTL_PLMN_SEARCH - initiates PLMN (carrier) search on pre-configured
EARFCN (Absolute Radio Freqency Number);
- RRCTL_PLMN_SELECT - binds the UE to one of the previously detected
carriers (see RRCTL_PLMN_SEARCH) defined by a
given pair of MCC and MNC;
- RRCTL_CONN_ESTABLISH - establishes connection to the serving cell
(previously selected using RRCTL_PLMN_SELECT)
with a given cause and NAS PDU;
- RRCTL_CONN_RELEASE - releases previously established dedicated connection
(currently does nothing because the RRC layer does
not expose any API for that);
- RRCTL_DATA - encapsulates a received (Downlink) or to be transmitted
(Uplink) NAS PDU (the former also contains LCID).
Each message type has at least two of the following sub-types:
- RRCTL_REQ - request (usually comes from an external NAS entity),
used to initiate some process (e.g. PLMN search);
- RRCTL_IND - indication that something has happened without a prior
request (for example, a Downlink NAS PDU was received);
- RRCTL_CNF - confirmation (positive conslusion) of the requested task;
- RRCTL_ERR - negative conslusion of the requested task (error).
The protocol definition (enums ans structs) and codec functions are
defined in a separate namespaces: 'rrctl::proto' and 'rrctl::codec'
respectively. The codec functions may throw exceptions of type
'rrctl::codec::error' if something goes wrong.
Unfortunately, the existing networking API (common/network_utils.h)
lacks the UNIX domain socket support, and it turned to be easier
to implement a simple, single client server using Boost.Asio.
The server runs in its own thread with a blocking Tx queue, and
calls a user definted callback on receipt of any data from client.
Multiple client connections are not supported and will be rejected.
This commit introduces a skeleton class (child of 'nas_base') for
the upcoming implementation of an external NAS interface, as well
as the implementation-specific configuration container.
This is the first step towards the goal of having an external NAS
interface. The new 'nas_base' class becomes a parent of 'nas',
combining all interfaces and the basic (common) API.
The 'ue_stack_lte' now holds a unique_ptr of type 'srsue::nas_base',
so the underlying NAS implementation (built-in or external) can
be choosen at run-time depending on configuration.
The implementation specific configuration now needs to be passed
to the constructor instead, not to the init() method as was before.
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
* 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.
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.
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.
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
Vadim Yanitskiy
Sylvain Munaut
Daniel Willmann