2016 8th International Conference on Computational Intelligence and Communication Networks

Advancement of FAPI Error Indication

Messaging for 4G Systems
Mudassar Khan, Ajay Sharma & Somasekhar Pemmasani
PARALLEL WIRELESS
PUNE INDIA

Abstract—Fast Application Programming Interface Protection Messaging. Section IV provides details on

better known as FAPI is a standard in which exchange the Advancement of the Error Protection Message
of information between the two layers is performs via about the structure and how it will relay the
certain message structures. 4G systems of today such as information to Layer 2. Section V provides a details
Long Term Evolution (LTE)can make use of this FAPI example of the overall Error Protection Messaging.
standards in order to exchangeconfiguration between Section IV contains the conclusion.
the different Layers as well as providing indications and
errors. This paper focuses on introducing II. INTRODUCTION TO FAPI FOR LTE 4G
anAdvancement in the Error Indication Messages for a SYSTEMS.
LTE based system which would relay the information
from Layer 1 to Layer 2 about the configurations which The LTE FAPI developed by the Femto Forum
have encountered an error and also providing details of describes the FAPI standard by dividing it into two
the area of code in which the issue was found in Layer sections.
1. The Layer 2 can utilize this information to avoid such
ƒ Providing a description of typical procedures
configurations to be sent down to Layer 1 and to instead
send the next best known configuration and to avoid
which will occur between the L1 and L2/L3
any crash scenarios. These details can also provide a software.
detailed level of debugging on the Layer 1 level ƒ Providing the definition of the L1 API messages.
reducing the debugging time allowing more efficiency
by detecting and pinpointing issues or bugs. In this section a brief description of the two sections is
covered.
Keywords: FAPI, LTE, Crash Avoidance, FAPI Error
Indication L1 & L2/L3 PROCEDURES.
This section gives an overview of the procedures
I. INTRODUCTION.
which use the L1 API. These procedures are split into
FAPI is like any other API a set of routines, rules two groups, namely, configuration procedures and
or protocols which are used to build or connect sub-frame procedures. Configuration procedures
software components. In the case of 4G systems such handle the management of the PHY layer and are
as LTE, FAPI standards have already been developed expected to occur infrequently. Sub-frame procedures
by LTE Femto Forum. The FAPI standard draws a determine the structure of each 1ms sub-frame and
clear conclusion on how a LTE based layered system
operate with a 1ms periodicity.The configuration
is connected with one another and how information
procedures supported by the L1 API are[1]:
exchange is carried out as a whole. The focus of the
paper is to introduce an advancement to the error ƒ Initialization
indication message which can provide detailed ƒ Termination
information about the wrong configurations that are ƒ Restart
arriving from the Layer 2 to the Layer 1. This detailed ƒ Reset
information can be utilized to prevent Layer 2 to send ƒ Error notification
such configurations to Layer 1. A database with the
Layer 2 to log such wrong configurations with
timestamps can be useful for debugging purpose by These procedures will move the Layer 1 through the
pinpointing exactly at which location in the Layer 1 IDLE, CONFIGURED and RUNNING states [1], as
the issue are found. shown in Figure 1. A list of the L1 API configuration
messages which are valid in each state is given in
The paper is spilt into various section. An TABLE 1
introduction to LTE based FAPI message exchange
and the details are covered in Sections II. Section III
introduces the benefits of the Advancement of Error

978-1-5090-1144-5/16 $31.00 © 2016 IEEE 28

DOI 10.1109/CICN.2016.14
 Figure 1: Layer1 States

Table1: L1 API configuration message

Idle State Configured State Running State

PARAM.request PARAM.request CONFIG.request

CONFIG.request CONFIG.request STOP.request

START.request

L1 API MESSAGES.
However it has been observed during the development
The general message format of the L1 API is stages that the details provided to the Layer 2 in the
shown in Table 3-1, where it can be seen that each L1 error indication message is not sufficient to pinpoint
API message consists of a header followed by a the precise issue which results in a great amounts of
message body [1]. The generic header consists of a round time debugging. A modification to the error
message type ID, a message body length and a indication message is been proposed to ease this issue.
vendor-specific body length. The current list of
message types is given in Table 2. The L1 API The details of the modifications are provided in
messages follow a standard naming convention section IV. Wrong configurations can occur due to
where: various reasons (i.e. Layer 2 sending wrong
parameters, corruption on memory on Layer 1 etc.)
ƒ All request messages are sent from the L2/L3 which could result in serious demerits to the overall
software to the PHY. system. For instance in a scenario when a wrong
ƒ All response messages are sent from the configuration arrives at the Layer 1 the Layer 1 may
PHY to the L2/L3 software. These are sent in not be in a position to process the data received.
response to a request. Hence resulting in a drop in throughput and further
ƒ All indication messages are sent from the causing CRC failure and retransmission. In a case
PHY to the L2/L3 software. These are sent when multiple CRC failures occur and the system has
asynchronously. reached its maximum retries, the User Equipment
(UE) may move into the link loss state. The UE going
III. BENFITS OF ADVANCE ERROR into link loss would require a re-network entry in
INDICATION MESSAGE. order for it to attach back onto the network. This
The current FAPI error indication message indeed would result in wastage of resources and
provides certain details to Layer 2 at various levels. would reduce the efficiency of the network system.

29
 The Advance Error Indication message can also The L1 API message formats for the
provide additional information which would help to ERROR.indication message is shown below in
pinpointing the location at which the issue was found TABLE 2 & 3.
in the Layer 1. The Advance Error Indication message
can also be extended to a further use by providing a Sub error message body has passed second level of
support over Layer 2, where such issue faced at Layer error code. But it has limited information passed to
1 can be recorded onto a database. This database can L2, its more generic code. The sub error code are
be useful to the Layer 2 scheduler where the future giving the extra level of information about what sub
configurations can be compared with the error has been hit out of 4 classified error (sfn_error,
configurations in database before being applied. If pdu_error, hi_error or tx_error). So to improve the
such a configuration is found then the next best error protection mechanism need to give more and
configuration could be applied to avoid any further accurate error indication so the MAC can take the
issues on the Layer 1. decision more effectively. Apart from the boundary
checks can send the board specific limitation to MAC
so it will avoid such combination which is unable to
IV. DETAILS OF ADVANCE ERROR support.
INDICATION MESSAGE.
The advancement to error indication message can be
divided into 5 levels of error protection For example if number of PDUs (like BCH PDUs,
PDSCH PDUs etc.) came wrong can be reported back
• Error level-1: It covers all parameters coming via to MAC in a SF. ALL DL and UL config parameters
FAPI. In this level we have boundary checks of boundary check will have unique error travelled back
all the parameters coming within a FAPI message so MAC can configure correct one or take necessary
(Only DL_Config and UL_Config FAPI action to avoid it.
parameters)[1], the Cell config parameters returns
Invalid message this range checking is not part of ƒ MSB is set to 1 for error (Bit 31).
error level-1. ƒ Next two bits for type of error (Bit 30 and 29),
• Error level-2: It covers the checks on total which are :
number of DL and UL PDUs supported by L1. • Information (01) : This error code type are
• Error level-3: It covers the scheduling limitations Informative only, which is not Introducing
/ tradeoffs that exist in L1 based on the any major error but useful to convoy it to L2
computation capacity or design. For example, L1 for scheduling the parameter next time. This
cannot process the RACH and SRS together in a error code can be overwritten by both the
single SF, so accordingly check is placed such Non-fatal and fatal error type.
that when higher layers try to schedule RACH • Non-Fatal (10) : These error code types are
and SRS together then L1 will report appropriate not breaking the system, but violation of the
error. parameter for the current SF. This error code
• Error level-4: It covers the error that exists at can be overwritten by fatal error type.
component level limitation which can be pointer • Fatal (11) : These error code types are able to
violation or memory alignment Issue. break the L1-SW, this error code is highest
• Error level-5: It covers the error that exists at priority. If this type comes need to return
component level limitation check. It may be due from then and there no further processing
to calculated parameters based on the FAPI will done.
parsing parameters or scheduling related problem ƒ Next three bits for what technology the error code
in L1 component is generating (Bit 26 to 28)
ƒ Next five bits is used for the Component, these
The ERROR.indication message is reported back are unique values for each module (Bit 21 to 25)
by the L1 to the MAC in each subframe procedure ƒ Next three bits for the sub module representation,
using applicable limited error code for each which can be used manager/ kernel levels (Bits
messages[2].If the L2/L3 software receives an 18 to 20). Below Modules is using those 3 bits to
ERROR.indication message for DL_CONFIG.request, declare its sub modules
UL_CONFIG.request, HI_DCI0.request or ƒ Next nine bits are reserved.
TX.request, it should assume that the UE did not ƒ The 8th bit is used as flag for next 2 byte error
receive data and control sent in this subframe. code. It is set as ‘1’.
ƒ From LSB, 8 bits are used for error code, these
are unique 256 error belong to each sub-module

30
 Table 2: Error Indication Message Body

Field Type Description

msgStatus FAPI_MESSAGE_STATUS_T Indicate the message status
message_id UINT8 Indicate which message received by the PHY has an error.
padding UINT8 To make error code aligned to 32-bits (3 Bytes padding)
error_code UINT32 The error code
sbl_error_msg_body union Error code dependent values. The format of these bytes is
dependent on the error code. See Below Tables for details

Table 3: sbl_error_msg_body Message Body

Field Sub-Field Type Description

sfn_error received_sfn_sf UINT16 Received subframe number

expected_sfn_sf UINT16 Expected subframe number

pdu_error sub_error_Code UINT8 Configuration or component level error code

direction UINT8 Indicates if this error was in a DL subframe configuration or

an UL subframe configuration.

Rnti UINT16 The RNTI in the received PDU.

pdu_type UINT8 The PDU Type parameter specified in both DL subframe

configuration and UL subframe configuration.

Padding UINT8 Padding One byte

hi_error sub_error_code UINT8 Configuration or component level error code

phich_lowest_ul_rb_index UINT8 PHICH lowest UL RB index

tx_error sub_error_code UINT8 Configuration or component level error code

pdu_index UINT16 PDU index

comp_error sub_error_code UINT32 Component level error code for protection level 4 and 5

Figure 2: Bit fields for ERROR Code

Field is parsing number 7 which is not a valid DCI

V. ERROR PROTECTION MESSAGE format then a unique error code is reported to L2.
EXAMPLE. Similarly all PDUs per sub-frame is checked and
parsed.
Error level 1 Example:
if(dci_format > 7)
In error level 1 all PDUs parsing parameters have {
boundary check e.g. DCI PDU. If the DCI Format error = ERROR | FATAL | SPM_FAPI |
SPM_PDCCH |ERROR_DCI_FORMAT)

31
Error level 2 Example:
VI. CONCLUSION.
If the number of PDU that can be processed in a sub-
frame is out of limit it can lead to a crash at the L1. The Error indication message had been modified to
Like if UE is expecting a DLSCH PDU but PHY provide better detailed information about the errors
receives less or more number of PDUs (max 16 PDUs being reported. It can be seen that with help of the
can be process in a Sub-Frame) then, It will leads to advancements explained in section IV better
an error which can be communicate to the L2. information can help the developers and tester to
locate the issue in real time, rather than try to capture
and analyze the logs. This will provide a benefit the
if (dlsch_pdu>16) debugging process reducing the overall time. The
{ paper only discusses one of the many different
error = ERROR | FATAL | SPM_FAPI | possible ways this error indication message can be
SPM_PDSCH | ERROR_MAX_DLSCH_PDU) modified to serve better use. The advance error
} indication was pertaining to specific Layer 1 design
and can be modified henceforth other Layer 1 specific
designs.
Error level 3 Example:
VII. REFERENCE
Another example is when L1 cannot process the
RACH and SRS together in a single SF, so [1] Small Cell Forum, Release 5, LTE SCAPI,
accordingly check is placed such that when higher March 2015.
[2] 3GPP Evolved Universal Terrestrial Radio
layers try to schedule RACH and SRS together then
Access (E-UTRA); Medium Access
L1 will report appropriate error.
Control(MAC) protocol specification TS36.321
Error level 4 Example [3] 3GPP Evolved Universal Terrestrial Radio
Access (E-UTRA); Physical Layer procedures
A simple but common issue is when pointers are not TS36.213
assigned and are initialized as NULL. During such [4] 3GPP Evolved Universal Terrestrial Radio
cases the pointers need to be assigned to a proper Access (E-UTRA);Multiplexing and channel
address and if found pointing to a NULL could cause coding TS36.212 V10.8.0
issues on the L1 code base.
if ( (spm_tdp_dynamic == NULL) || (spm_tdp_static
== NULL))

error = (ERROR | FATAL | SPM_PRACH |

SPM_PRACH_TDP | ERROR_NULL_POINTER);

return error;

IF4_samp_ant0 = spm_tdp_dynamic-
>IF4_samples_ant0;

if ( ( IS_ALIGNED_SPLIB(IF4_samp_ant0,
ALIGNED_8_BYTES) == 0) )

error = (ERROR | NON_FATAL

|SPM_PRACH|SPM_PRACH_TDP|
ERR_4_PRACH_TDP_NOT_ALIGN);

32