Tips and Terminologies for LTE Protocol

If you wants to have just overview of LTE, this section would not help you much, but if you are interested in protocol stack development or test case development these may be good tips. In many cases in this area, you will notice that a seemingly simple concept will turn out to be very complicated in terms of implementation. Just try to have overall idea on multiple parameters and their dependencies for a specific feature. RB Size For Resource Allocation Type 0 which is the most common resource allocation type, there is a rules for DL_RB setting if if if if if if System System System System System System BW BW BW BW BW BW = = = = = = 1.4 M, it should be multiples of 1 (1 x n) 3 M, it is should be multiples of 2 (2 x n) 5 M, it should be multiples of 2 (2 x n) 10 M,it should be multiples of 3 (3 x n) 15 M, it should be multiples of 4 (4 x n) 20 M, it should be multiples of 4 (4 x n)

This rule is derived from the Resource Block Group(RBG) size for each bandwidth, and the RBG size for system bandwidth is shown in TS 36.213 Table 7.1.6.1-1. (Number of DL RB should should be the multiples of RBG for the corresponding system bandwidth) * Reference for additional restriction and details : TS 36.104 Table 5.2.1 for DL (Number of RBs for each System BW), TS 36.211 Section 5.3.3 for UL (UL_RB = 2^a x 3^b x 5^c) Throughput Calculation Example If you know the MCS index, you can calculate the throughput for that specific MCS idex as follows: Calculation Procedure for downlink(PDSCH) is as follows : i) refer to TS36.213 Table7.1.7.1-1 ii) get I_TBS for using MCS value (ex, I_TBS is 21 if MCS is 23) iii) refer to TS36.213 Table7.1.7.2.1 iv) go to column header indicating the number of RB v) go to row header 21 which is I_TBS vi) you would get 51024 (if the number of RB is 100 and I_TBS is 21) vii) (This is Transfer Block Size per 1 ms for one Antenna) If we use 2 antenna, it is 51024 bits * 2 Antenna * 1000 ms = about 100 Mbps Calculation Procedure for uplink(PUSCH) is as follows : Same as the downlink as above except that you have to refer to 36.213 Table 8.6.1-1 at step i)

Uplink Analysis Paremeter Calculation Meaning of MS269x parameters: i) Sequence Group Number : This means "u" value described in TS36.211 v8.7.0 5.5.1.3 Group hopping ii) Base Sequence Number : This means "v" value described in TS36.211 v8.7.0 5.5.1.4 Sequence hopping iii) Cyclic Shift Index : This means "n_cs" value described in TS36.211 v8.7.0 5.5.2.1.1 Reference signal sequence Relationship between Items and parameters in C Scenario: i) Sequence Group Number u = ( ( CellID % 30 ) + deltaSS ) % 30 CellID: Cell ID specified by parameter file(.pme) deltaSS: LteCphyUlConfigUL_SCH.ULRSConfig.GroupAssignment ii) Base Sequence Number Fixed to 0. iii) Cyclic Shift Index n_cs = ( n1_DMRS + n2_DMRS + n_PRS(n_s) ) % 12 n1_DMRS: Calculated from CphyUlConfigUL_SCH.RSSoundConfig.Dedicated.CyclicShift n2_DMRS: Fixed to 0. n_PRS(n_s): Calculated from the following scenario parameters.( Please refer to above spec ) Code Rate When you have unrestricted resource to allocate for a certain UE, it would be happy. Even when you develop call processing protocol sequence to test UE, there may be times when you want to allocate a bare minimum resource for a certain data traffic. Then the issue is how to figure out the bare minimum resource for the traffic. If you allocate the resource less than the minimum value, the data would not get trasmitted or would not get decoded even though it got transmitted. For this there is a guideline in 3GPP specification. TS36.213 7.1.7 Modulation order and transport block size determination and it says as follows. The UE may skip decoding a transport block in an initial transmission if the effective channel code rate is higher than 0.930, where the effective channel code rate is defined as the number of downlink information bits (including CRC bits)divided by the number of physical channel bits on PDSCH. If the UE skips decoding, the physical layer indicates tohigher layer that the transport block is not successfully decoded. For the special subframe configurations 0 and 5 withnormal CP or configurations 0 and 4 with extended CP, shown in table 4.2-1 of TS 36.211: Evolved Universal Terrestrial Radio Access (E-UTRA); Physical channels andmodulation, there shall be no PDSCH transmissionin DwPTS of the special subframe. Let's take an example with MCS = 8 and No of RBs = 3. For this we have to get the two numbers based on specification quoted above. (i) number of downlink information bits (including CRC bits ) (ii) number of physical channel bits (i) refers to "(Transport Block Size + CRC bits)" which is the size of the message that gets channel coded. (ii) refers to the number of available bits in the PHYSICAL LAYER. Each resource element(RE) can carry 2, 4, or 6 bits depending on the modulation scheme.We just have to count the number of REs reserved for PDSCH transmission on each subframe, and then multiply it by 2, 4, or 6 (accordint to modulation scheme) and then we will have the number

of physical channel bits on PDSCH. Getting back to our example condition MCS = 8 and No of RBs = 3. In this case, for item (i), we can easily figure this out from TS36.213 Table7.1.7.1-1 for item (ii) we have a) 3 x 12 REs/symbol b) (14 symbols/subframe) x (3 x 12 REs/symbols) = 504 REs/subframe. Out of this 504 REs, we have to remove those REs allocated for PDCCH since it is not carrying the real data. Let's assume that 3 symbols/subframe are allocated for PDCCH. In this case, the number of REs for avaiable in PHY LAYER for data transmission is 504 - (3 x (3 x 12)) which is 396. Now we have to convert this number into "number of bits". In our sample case, the modulation scheme is QPSK which carries 2 bits per RE. Therefore, the value for item (ii) is 2 x 396 = 792. This assumes that the subframe does not carry PBCH, PSS, SSS. If it is the subframe that carries these signals, we have to remove the REs for PBCH, PSS, SSS as well. Now we have the value (i) and (ii). If you take (i)/(ii), you will get the Code Rate. I admit the explanation above would sound too complicated and messy. I asked on this to another expert on this area and he gave me much clearer explanation as follows : The code rate is the result (consequence) of the combination of TBS, MCS, and N_RB we have chosen for the transmission. Effective channel code rate is defined as the number of downlink information bits (including CRC bits) divided by the number of physical channel bits on PDSCH Let us take the caseMCS=8; ITBS=8, TBS=808; N_PRB=6 The number of downlink information bits =808+24 (CRC bits) = 832The number of physical channel bits on PDSCH = 6 (N_PRB)*12(no. of subcarriers in a PRB)*7(number of OFDM symbols in a slot)*2(no. of slots in a subframe)*2(number of bits per modulated symbols)=2016 Effective channel code rate = 832/2016 = 0.4127 Basically, the encoder is a fixed 1/3 code. The rate matching unit takes out different number of coded bits before transmission in the channel

Units for Resource Allocation and Management Reading various LTE specification, you will see many terms which seems to be related to resource allocation but looks very confusing. At least you have to clearly understand the following units. i) Resource Element ii) Resource Element Group (REG) : a group of 4 consecutive resource elements. (resource elements for reference signal is not included in REG) iii) Control Channel Element (CCE) : a group of 9 consective REG Calculating CCE Index CCE Index is the CCE number at which the control channel data is allocated. Normally this

index changes for each subframe, meaning that the control channel data allocated in each subframe changes subframe by subframe. One of the most common situations where you have to care about this CCE index is when you change the system BW. Changing the system bandwidth in higher layer (L3) is very simple. You only have to change one IE in MIB, but if you are a protocol stack developer or test case developer who take care of all stack from L1 through L3, you have to calculate CCE index for each subframe and those index gets different for each bandwidth. But calculating CCE is not a simple procedure. Just outline of the calculation is as follows. Just try to have an idea on which parameters you need and how they are related to calculate CCE. i) Prepare REG Table ii) Select the system BW(=BW) iii) Get the max number of RB for the BW (=N_RB) iv) Select the Number of HI Group (=No_HI_Group) v) Set the REG using CFI (REG_CFI = 4) vi) Select the CFI (=CFI) vii) Get Ng (=Ng) viii) Create CFI vs BW table using Ng, REG_CFI, No_HI_Group (=CFI_BW_Table) ix) Create HI_Group vs. BW table using Ng,N_RB (=HI_Group_BW_Table) x) Get the element from HI_Group_BW_Table where BW and Ng cross.(=HI_Group) xi) Get the element from CFI_BW_Table where CFI and BW cross(=N_CCE) xii) Select CRNTI xiii) Specify A,D,Y-1,Lx iv) Calcuate Y0~Y9 from A,N_CCE,D xv) Specify Aggregation Level(=L, where L = {1,2,4,8}) xvi) Calculate CCE Index from L,Y0~Y9,N_CCE DCI(Downlink Control Information) DCI carries the following information : i) UL resource allocation (persistent and non-persistent) ii) Descriptions about DL data transmitted to the UE. L1 signaling is done by DCI and Up to 8 DCIs can be configured in the PDCCH. These DCIs can have 6 formats : 1 format for UL scheduling, 2 formats for Non-MIMO DL scheduling, 1 format for MIMO DL Scheduling and 2 formats for UL power control. Format Format Format Format Format 0 : UL SIMO and UL Power Control 1, 1 A : DL SIMO and UL Power Control 2 : DL MIMO and UL Power Control 3 : UL Power Control Only (for multiple UEs) 3A : UL Power Control Only (for multiple UEs)

DCI has various formats for the information sent to define resource allocations. The resource allocation information contains the following items in it. i) number of resource blocks being used ii) duration of allocation in TTI iii) support for multiple antenna transmission Types of DCI are as follows :

Type 0 : A bitmap indicating the resource block groups(RBGs) that are allocated to the scheduled UE. (An RBG is a set of consecutive physical resource blocks(PRBs). This type has following informations * Flag for format 0/format1A differentiation * Hoping flag * Resource block assignment and hopping resource allocation * New data indicator * TPC command for scheduled PUSCH * Cyclic shift for DM RS * CQI request * Number of appended zeros to format 0 Type 1 : A bitmap indicating PRBs from a set of PRBs from a subset of resource block groups determined by the system bandwidth. * Resource allocation header (resource allocation type 0/type 1) * Resource block assignment * Modulation and coding scheme * HARQ process number * New data indicator * Redundancy version * TPC command for PUCCH Type 2 : A set of contiguously allocated physical or virtual resource blocks. The allocations vary from a single PRB upto the maximum number of PRBs spanning the system bandwidth. For more details for DCI, refer to http://jaekuryu.blogspot.com/2010/06/dci.html

LTE Basic Procedures

You can use this section as a kind of dictionary explaining fundamental concept of various signaling components. Topics described here are as follows and more topics will be added. Fundamental Information Initialization Sequence Primary and Secondary Secondary Sync Time Sync Process Cell ID Detection System Informations Random Access Uplink Data Transmission Scheduling - Persistent Scheduling

Fundamental Information UE Capability : UE Category, Frequency Band, Sync Signal Sequence, General Radio Resource Info, General MIMO Parameter, Duplex Mode, Preamble sequence generation algorithm SIM : Network Operator's PLMN list, Subscription Information Stored Information : Most recently used frequency band, PLMN, Tracking Area Code, Cell ID, S-TMSI, InterRAT Frequency Band Information that UE needs to get: Frequency and Timing Synchronization info, System Bandwidth, Number of MIMO Antennas, Identities (C-RNTI, Physical Cell ID, Tracking Area Code), Network PLMN, Signaling & Traffic Radio Resouce, RACH_ROOT_SEQUENCE & PRACH Config. Initialization Sequence i) Power-Up Test ii) Frequency & Time and Frame Synchronization iii) Decode System Information Message iv) Select Prefered Network v) Perform RACH Process vi) RRC Connection Setup Frequency Aquisition i) Search the center frequency by searching DC part ii) Decode BCH which occupies 62 subcarriers (6 RBs) at the center frequency. iii) BCH tells the frequency information of the system (eg. System Frequency Bandwidth) Primary and Secondary Secondary Sync i) Each cell transmit one of 162 unique sequences on its secondary sync channel (each bit sequence is 62 bit sequence) ii) The seconday Sync code is one of three unique sequence (62 bit Zadd-off chu sequence) which is carried by Primay Sync

iii) So total number of ID become 162 x 3 = 504 Time Sync Process i) UE decode Primary sync with three different Primary Sync Sequence and figure out which sequence is assigned for the cell and abtain the primary time sync as well. ii) Apply the primary sync sequence with the Secondary Sync code and figure out which sequence is assigned for the cell. This Sync detection is done every 5 ms. (You will understand this time interval if you look at the LTE Downlink frame structure explained at http://jaekuryu.blogspot.com/2010/01/firstthing-you-have-to-be-familiar.html) As I mentioned in previous section, three different sequences are used as the primary sync signal and there is a one-to-one mapping between each of the three sequences and the cell ID within the cell identity group. After a UE detect this cell-identity group, it can determine the frame timing. From this cell identity group, the UE also figure out which pseudo-random sequence is used for generating the reference signal in the cell. Cell ID Detection and System Information Detection i) Frequency Aquisition ii) Primary Sync Signal Aquisition (Slot Timing Aquired, Secondary Sync Signal Scrambling Code Aquired) iii) Secondary Sync Signal Aquisition (Frame timing Aquired, Cell Group ID sequence aquired) iv) with PSS and SSS, Cell ID can be calculated v) with Cell ID, Reference Signal Location is detected vi) If Reference Signal Location is properly decoded, PBCH (MIB) can be detected vii) From MIB, SFN and System BW can be detected viii) Decode PCFICH and detect how many symbols are allocated for PDCCH. ix) Decode DCI for SIB1 from PDCCH x) Decode SIB1 and get the scheduling information for other SIBs xi) Decode SIBs (other than SIB1) One of the most important step for testing/troubleshooting around the initial registration is to check whether UE successfully complete the time-sync (step i) and ii)), but it is very hard to check this step with any kind of equipment. One way to easily check whether UE succeeded in time-sync or not is to check from UE log whether UE successfuly decoded Cell ID or not. If UE successfully detected Cell ID, it means UE successfully completed the timesync.

System Information MIB i) DL Bandwidth, Number of Transmit Antenna, Reference Signal Transmit Power ii) System Frame Number (SFN) iii) PHICH Configurationiv) Transmit every 40 ms , repeat every 10 ms
MasterInformationBlock ::= SEQUENCE { dl-Bandwidth ENUMERATED { n6, n15, n25, n50, n75, n100},

phich-Config PHICH-Config, systemFrameNumber BIT STRING (SIZE (8)), spare BIT STRING (SIZE (10)) } SIB 1 i) Cell Access Related Information - PLMN Identity List, PLMN Identity, TA Code, Cell identity & Cell Status ii) Cell Selection Information - Minimum Receiver Level iii) Scheduling Information - SI message type & Periodicity, SIB mapping Info, SI Window length SIB 2 i) Access Barring Information - Access Probability factor, Access Class Baring List, Access Class Baring Time ii) Semi static Common Channel Configuration - Random Access Parameter, PRACH Configuration iii) UL frequency Information - UL EARFCN, UL Bandwidth, additional emmission Random Access Random Access process plays two main roles - establishment of uplink synchronization and establishment of a unique UE ID (C-RNTI) known to both the network and the UE.So Random Access is used not only for initial access, but also after periods of uplink inactivity when uplink sync got lost in LTE_ACTIVE states. i) UE initiate a Random Access Procedure on the (uplink) Random Access Channel (RACH).(The location of RACH in the frequency/time resource grid the RACH is known to the mobile via the (downlink) Broadcast Channel (BCH). The random access message itself only consists of 6 bits and the main content is a random 5 bit identity) ii) Network sends a Random Access Response Message(RARM) at a time and location on the Physical Downlink Shared Channel (PDSCH) (The time and location of RARM on PDSCH can be calculated from the time and location the random access message was sent. This message contains the random identity sent by the device, a Cell Radio Network Temporary ID (C-RNTI) which will be used for all further bandwidth assignments, and an initial uplink bandwidth assignment) iii) The mobile device then uses the bandwidth assignment to send a short (around 80 bits) RRC Connection Request message which includes it's identity which has previously been assigned to it by the core network Only the step i) uses physical-layer processing specifically designed for random access. The remaining steps utilizes the same physical layer processing as used for normal uplink and downlink data transmission. For further details of Random Access process, refer to http://jaekuryu.blogspot.com/2010/01/understand-rach.html Uplink Data Transmission Scheduling - Persistent Scheduling There are a couple of Data Transmission Scheduling Scheme in LTE. The most simple in terms of algorithm would be the persisent scheduling. In this scheduling mode, Network send 'Grant' in DCI Format 0 for every one subframe.

i) Network send the first data on DL PDSCH and PDCCH which has DCI format 1 for DL Data Decoding and DCI format 0 for UL Grant. (If there is no downlink data to be transmitted, network transmits only DPCCH with DCI format 0 without any DPSCH data) ii) UE decode PCFICH to figure CFI value. iii) UE decode PDCCH and get the information on DCI format 1 iv) Based on DCI format 1, UE decode DL data. v) UE decode the information on DCI format 0 from PDCCH vi) UE send ACK/NAK for DL data through UCI (UCI will be carried by PUCCH) vii) UE check the Grant field. viii) If Grant is allowed, UE transmit the uplink data through PUSCH ix) Network decode PUSCH data and send ACK/NACK via PHICH x) UE decode PHICH and retransmit the data if PHICH carries NACK For detailed data structure of DCI Format 0, refer to TS 36.212 section "5.3.3.1.1 Format 0" The process listed above is in reality a pretty complicated process and need a lot of troubleshoot and debugging. So in case of development and testing phase, we normally break down this process into multiple simple/small procedure and verifies it step by step. Step 1 : DL data reception and no ACK/NACK transmission ==
a) Network send PDCCH and PDSCH data b) See if UE properly decode PDSCH data This would seem to be very simple two step process, but to make this happen UE is capable of doing step ii), iii), iv) described above.

Step 2 : DCI format 0 reception ==

a) Network send DCI Format 0(UL Grant) without PDSCH transmission b) See if UE properly decode DCI Format 0 (You need to make it sure that Resource allocation that UE decoded matches with DCI format 0 sent by network.)

Step 3 : PUSCH transmission based on DCI format 0 == a) Network send DCI Format 0(UL Grant) without PDSCH transmission b) UE transmit UL Data on PUSCH c) Network decode PUSCH data d) see if the data decoded at Network side maches what UE transmit To make this happen, UL DMRS for PUSCH should have been properly implemented and you have to make it sure that UE transmit the PUSCH data on the RBs that DCI format 0 specified. Step 4 : DL data reception and ACK/NACK transmission a) Network send PDCCH and PDSCH data b) UE decode PDSCH data c) UE has to transmit ACK/NACK accordingly Step 5 : UL data transmission and ACK/NACK reception

==

==

a) Network send DCI Format 0(UL Grant) without PDSCH transmission b) UE transmit UL Data on PUSCH c) Network decode PUSCH data d) Network send ACK/NACK on PHICH e) UE has to decode ACK/NACK properly f) UE has to retransmit the data if it gets NACK Decoding Uplink Signal 'Decoding Uplink Singal' means 'decoding PUCCH and PUSCH'. But eNode be normally get Uplink signal from multiple UEs and each of the UE may be in different distance and under different channel condition. So docoding uplink channel would not be easy. To help eNode be decode these uplink channel, UE transmit a reference signal. There are a few different uplink signal as listed below. i) DMRS (DeModulation Reference Signal) for PUCCH ii) DMRS (DeModulation Reference Signal) for PUSCH iii) Sounding Reference Signal. Item iii) would not be a mandatory component, but UE must send item i) and ii). Otherwise, eNodeB fail to decode PUCCH or PUSCH even though UE transmit it in proper format. Detailed implementation of UL reference signal is described in TS 36.211 section 5.5 and TS 36.213. You will notice a lot of parameters are involved in UL reference signal generation and the following is brief list of these parameters. * n_1_pucch : N(1)PUCCH described in 3GPP TS36.213 * GroupHopping : 5.5.1.3 in TS36.211 * Cell ID : * Pucch format : 5.5 in TS36.211 * N_1_CS : * N_2_RB : * delta Pucch shift : * RNTI : * UL CP Configuration : * systemBW : * u_even : sequence-group number even slot (TS36.211 5.5.1.3) * u_odd : sequence-group number odd slot (TS36.211 5.5.1.3) * n_cs_even#0~#6 : Cyclic Shift for even slot in a subframe (TS36.211 5.4.1, 5.5.2.2.1) * n_cs_odd#0~#6 : Cyclic Shift for odd slot in a subframe (TS36.211 5.4.1, 5.5.2.2.1) * n_oc_bar_even : orthogonal sequence for even slot in a subframe (TS36.211 5.5.2.2.1) * n_oc_bar_odd : orthogonal sequence for odd slot in a subframe (TS36.211 5.5.2.2.1) * n_oc_even : orthogonal sequence for even slot in a subframe (TS36.211 5.4.1) * n_oc_odd : orthogonal sequence for odd slot in a subframe (TS36.211 5.4.1) * n_PRB_even : Physical resource block number for even slot in a subframe (TS36.211 5.4.3) * n_PRB_odd : Physical resource block number for odd slot in a subframe (TS36.211 5.4.3) As you notice, quite a lot of parameters are involved and it is not easy to understand all of these in detail, but at the initial phase of chipset development or when you try to duplicate live network environment with network simulator you have to make it sure that all of these parameters are properly setup not only in UE but also in network simulator.

Can UE set these parameters arbitrarily whatever it likes to do ? No.. in that case eNode B would not know how to detect the reference signal and in result eNode B would not be able to decode PUCCH/PUSCH. Then how UE can know which value it has to use for Uplink Reference Signal Creation ? The most critical information on UL Reference Signal is tranmitted by SIB2 message as follows : * * * * radioResourceConfigCommon.pucch_ConfigCommon.deltaPUCCH_Shift radioResourceConfigCommon.pucch_ConfigCommon.nRB_CQI radioResourceConfigCommon.pucch_ConfigCommon.nCS_AN radioResourceConfigCommon.pucch_ConfigCommon.n1PUCCH_AN

Tracking Area Update Request

The TRACKING AREA UPDATING (TAU) procedure is always initiated by the UE and is used for (some of) the following purposes: Normal TAU: When the UE enters a tracking area that is not in the list of tracking areas that the UE previously registered in the MME Combined TAU: When a UE operating in 'CS/PS mode 1' or 'CS/PS mode 2' enters a tracking area that is not in the list of tracking areas that the UE previously registered in the MME Periodic TAU: Upon the expiry of timer T3412, periodic TAU procedure is initiated to periodically notify the availability of the UE to the network IMSI attach for non-EPS services when the UE is attached for EPS services. This procedure is used by a UE in 'CS/PS mode 1' or 'CS/PS mode 2' of operation In various cases of inter-system change from Iu mode to S1 mode or from A/Gb mode to S1 mode or from S101 mode to S1 mode MME load balancing: When the UE receives RRC CONNECTION RELEASE message with cause load balancing TAU required', it initiates TAU procedure To update certain UE specific parameters in the network (ex:- when the UE changes the UE network capability information or the MS network capability information or the UE specific DRX parameter etc...)

The UE initiates the TAU procedure by sending TRACKING AREA UPDATE REQUEST message. The IEs (some of them are explained below) in this message include EPS update type, NAS key set identifier, Old GUTI, GPRS ciphering key sequence number, Old P-TMSI signature, Additional GUTI, UE network capability, Last visited registered TAI, DRX

parameter, UE radio capability information update needed, EPS bearer context status, MS network capability, Old location area identification, Supported Codecs, Additional update type, Voice domain preference and UE's usage setting, Device properties etc

In the IE EPS update type the first 3 bits (LSBs) shall be used to indicate update type (ex:- TA updating or combined TA/LA updating or combined TA/LA updating with IMSI attach or periodic updating). Additionally, if a UE has uplink user data pending when it initiates the TAU procedure or uplink signalling not related to the TAU procedure, it may also set an "active" flag (bit4) in this IE to indicate the request to establish the user plane to the network and to keep the NAS signalling connection after the completion of the TAU procedure

The IE Old GUTI shall be handled as follows: UEs supporting A/Gb mode or Iu mode or both:

- If TIN = "P-TMSI" and the UE holds a valid P-TMSI and RAI, the UE shall map the P-TMSI and RAI into the Old GUTI IE, and include Old GUTI type IE with GUTI type set to "mapped GUTI". Additionally, if the UE holds a valid GUTI, then it shall be indicated in the IE Additional GUTI - If TIN = GUTI or RAT-related TMSI and the UE holds a valid GUTI, the UE shall indicate the GUTI in the Old GUTI IE, and include Old GUTI type IE with GUTI type set to "native GUTI" UEs not supporting A/Gb mode or Iu mode: The UE shall include a valid GUTI in the Old GUTI IE. In addition, the UE shall include Old GUTI type IE with GUTI type set to "native GUTI"

The IE Additional Update Type provides additional information about the type of request for a TAU procedure. Bit1 value 0 means that there is no additional information and 1 means that SMS only

Voice domain preference and UE's usage setting IE shall be included if the UE supports CS fallback and SMS over SGs, or if the UE is configured to support IMS voice, but does not support 1xCS fallback. This IE provides the network with the UE's usage setting and the voice domain preference for E-UTRAN. Refer to 3GPP TS 24.008, section 10.5.5.28 for detailed information

The IE Last Visited Registered TAI shall be included if the UE holds a valid last visited registered Tracking Area Identity (TAI)

The purpose of the Device properties IE is to indicate if the MS is configured for NAS signalling low priority. The network uses the Device properties IE for core-network congestion handling and for charging purposes. This IE can indicate MS is not configured for NAS signalling low priority or MS is configured for NAS signalling low priority

Reference: 3GPP TS 24.301 and 24.008

Example1: TRACKING AREA UPDATE REQUEST message (Normal TA updating)

Example2: TRACKING AREA UPDATE REQUEST message (Periodic TA updating)