Non-access stratum (NAS) is a functional layer in the UMTS and LTE wireless telecom protocol stacks between the core network and user equipment.[1]

 This layer is used to

manage the establishment of communication sessions and for maintaining continuous communications with the user equipment as it moves. The NAS is defined in contrast to the Access Stratum which is responsible for carrying information over the wireless portion of the network. A further description of NAS is that it is a protocol for messages passed between the User Equipment, also known as mobiles, and Core Nodes (e.g. Mobile Switching Center, Serving GPRS Support Node, or Mobility Management Entity) that is passed transparently through the radio network. Examples of NAS messages include Update or Attach messages, Authentication Messages, Service Requests and so forth. Once the User Equipment (UE) establishes a radio connection, the UE uses the radio connection to communicate with the core nodes to coordinate service. The distinction is that the Access Stratum is for dialogue explicitly between the mobile equipment and the radio network and the NAS is for dialogue between the mobile equipment and core network nodes.

The access stratum (AS) is a functional layer in the UMTS and LTE wireless telecom protocol stacks between radio network and user equipment.[1] While the definition of the

access stratum is very different between UMTS and LTE, in both cases the access stratum is responsible for transporting data over the wireless connection and managing radio

resources. The radio network is also called access network.

+- - - - - -+ +- - - - - - -+

| HTTP | | Application |

+- - - - - -+ +- - - - - - -+

| TCP | | Transport |

+- - - - - -+ +- - - - - - -+

| IP | | Internet |

+- - - - - -+ +- - - - - - -+

| NAS | | Network |

+- - - - - -+ +- - - - - - -+

| AS | | Link |

+- - - - - -+ +- - - - - - -+

| Channels | | Physical |

+- - - - - -+ +- - - - - - -+

UMTS Radio Resource Control

UMTS explicitly pulls out RRC as a distinct network function. GSM/GPRS had RRC, of course, in the RR sublayer of L3, but in UMTS RRC is pulled aside as a special function of its own instead of as a sublayer within L3. The general shape of UMTS RRC is the same as GSM/GPRS RR, but the actual resources and messages are different. 3GPP 25.331. Message encoding is ASN.1 unaligned PER as per  ITU-T X.691.

Handy Web References

 RRC FAQ.

Beacon Channel Generation

As in GSM, the UMTS beacon is a series of system information messages, actually called "system information blocks" or "SIBs". The SIBs are described in 3GPP 25.331 10.2.48.8:

MIB (Master Information Block) -- SIB scheduling information and MNC/MCC network identities

Type 1 -- Non-Access Stratum (NAS) system information:

o Location Area Code, as in GSM

o T3212 & Attach-Detach (ATT) flag for CS domains, as in GSM

o RAC and NMO for PS domains, as in GPRS

Type 2 -- UTRAN Registration Area (URA) identity list.

Type 3 -- Cell identity and reselect information, similar to GSM cell selection parameters

Type 4 -- Cell reselect parameters for connected mode, if different from those in SIB3. Optional.

Type 5 -- PRACH parameters, similar to GSM RACH parameters

o PRACH signature(s)

o PRACH scrambling code(s)

o PRACH spreading factor

Type 6 -- PRACH parameters for connected mode, if different from those in SIB5. Optional.

Type 7 -- PHY status

o uplink interference level for FDD

Type 8 (obsolete)

Type 9 (obsolete)

Type 10 (obsolete)

Type 11 -- Measurement control information.

Type 12 -- Measurement control information for connected mode, if different from SIB11. Optional.

Type 13 -- ANSI-41 system information. Not used in GSM-MAP networks.

Type 14 -- PHY information. TDD only.

Type 15 -- GPS aiding information. Optional? Time and reference position appear to by mandatory.

Type 16 -- PHY parameters related to handover

Type 17 -- TDD only.

Type 18 -- Neighbor identities. All elements are optional. Does that mean the whole message is optional?

The actual SIB formats are defined in ASN.1 in 3GPP 25.331 11. You can get a "clean" copy of that ASN.1  here.

3GPP 25.331 8.1.1.6 describes the UE actions to be taken upon receipt of the various system information messages. That information is very useful for understanding the actual meanings of some of the elements they contain.

SIB Scheduling (3GPP 25.331 8.1.1.1.5)

As per 3GPP 25.331 8.1.1.1.5, UMTS allows much more complex BCCH message scheduling than GSM. There is a Master Information Block (MIB, 3GPP 25.331 10.2.48.8.1) that defines the slot numbers on which the various SIBs will appear. Each MIB or SIB fills two consecutive frames, starting on an even-numbered slot. The MIB starts on SFN 0 and appears again on every 8th frame. The MIB contains a transmission schedule that describes when the other SIBs appear on the BCCH, in terms of a starting SFN and a repeat period. All of the parameters are powers of 2, but the repeat periods can be set independently for each SIB type. The fact that SIBs can span multiple transport frames, or be combined into shared transport frames, further complicates the set of scheduling possibilities.

The simplest way to schedule the messages would be:

non-segmented messages,

one SIB per transport frame,

schedule 3N messages with starting frames of 8*i+2, 8*i+4, 8*i+6 for i 0..(N-1) with a repeat period of 8N, where N is a power of 2.

Note that in this simple configuration, the MIB will appear N times in each cycle at SFN 8*i. For example, with N=4 we can schedule 12 messages at SFNs 2, 4, 6, 10, 12, 14, 18, 20, 22, 26, 28 and 30, with a repeat period of 32 and with the MIB at SFNs 0, 8, 16 and 24.

So, let's follow an SIB (a "System Information Block") from L3, where the fields of the SIB message receive their values, down through the stack to transmission. The best place to see this laid out in a clear way is in 3GPP 25.944 4.1.1.

Message Formation and ASN.1 Encoding

Following the ASN.1 encoding rules of 3GPP 25.331 11, we encode the SIB message to form a PER bitstring called a "production". There's an overview of this in 3GPP 25.331 12.1. This section tell us when delivering an RRC PDU as an RLC SDU to the RLC layer for transmission, the first bit of the RRC PDU shall be represented as the first bit in the RLC SDU and onwards. So the RRC PDU and the RLC SDU are the same, save any padding at the end.

There is a header on the RRC PDU of 20-24 bits, depending on the segmentation and concatenation rules used.

Forming a Transport Block

The BCH transport block is always 246 bits, including a header and data fields. The data field (the RRC PDU / RLC SDU) is end-padded as needed with zeroes to fit the BCH transport block.

FEC Coding

The 246-bit transport block gets a 16-bit CRC, an 8-bit tail and is then convolutionally coded at rate-1/2 to yield 2*(246+16+8) = 540 channel bits. The 540 channel bits are interleaved, split into 2 270-bit radio frames and interleaved again. (The standard channel model includes rate-matching, but the sizes line up already, so rate-matching is a no-op.)

Spreading and Scrambling

The BCCH is carried on the BCH and the BCH always has a spreading factor of 256, Each 270-bit radio frame gets spread to 69120 chips with an OVSF code (256,1) (ie, code #1 in the SF-256 set) and scrambled with the downlink code (a configurable parameter of the Node B). Note these comments on the alignment of the scrambling code, from 3GPP 25.213 5.1.4: The sequence of complex valued chips shall be scrambled (complex chip-wise multiplication)

by a complex-valued scrambling code Sdl,n. In case of P-CCPCH, the scrambling code shall be applied aligned with the P-CCPCH frame boundary, i.e. the first complex chip of the spread P-CCPCH frame is multiplied with chip number zero of the scrambling code. In case of other downlink channels, the scrambling code shall be applied aligned with the scrambling code applied to the P-CCPCH. In this case, the scrambling code is thus not necessarily applied aligned with the frame boundary of the physical channel to be scrambled. Wow!

Radio Transmission

These chips are formed into 34560 QPSK symbols and prepared for transmission with the root-raised-cosine channel filter. This 34560-symbol sequence is divided into 15 slots of 2304 symbols each. However, the P-CCPCH slot is 2560 chipping periods (10/15 ms @ 3.84 MHz). So what now? The first 256 chipping periods (1/15 ms) of each slot in the P-CCPCH is dead air, that's what.

PRACH Procedure

RACH transmissions from the user consists of two parts: (a) a sequence of preambles and (b) a message part. The channel format and other details are outline in 3GPP 25.211 5.2.2.1.

The random-access transmission is based on a Slotted ALOHA approach with fast acquisition indication. The UE can start the random-access transmission at the beginning of a number of well-defined time intervals, denoted access slots. There are 15 access slots per two frames and they are spaced 5120 chips apart (over 2 UMTS frames). The timing of the access slots and the acquisition indication is described in subclause 7.3. Information on what access slots are available for random-access transmission is given by higher layers.

The RACH procedures is as follows:

1. The terminal decodes the BCH to find out the available RACH sub-channels and their scrambling codes and signatures.2. The terminal randomly selects one of the RACH sub-channels from the group its access class allows it to use. Furthermore, the signature is

also selected randomly from among the available signatures indicated in SIB5.3. The downlink power level is measured and the initial RACH power level is set with the proper margin due to the open-loop inaccuracy.4. A 1 ms RACH preamble is sent with the selected signature.5. The BTS sends an AICH preamble. The terminal decodes AICH the preamble.6. If no AICH is detected, the terminal increases the preamble transmission power by a step given by the BTS, as multiples of 1 dB. The preamble

is retransmitted in the next available access slot. This cycle continues until the UE receives the AICH. The purpose of this procedure is to establish the appropriate uplink power level for the UE, since CDMA is exquisitely sensitive to variations in relative received power.

7. When the AICH transmission is detected from the BTS, the terminal transmits the 10ms or 20ms message part of the RACH transmission and DCH assignment proceeds.

RACH Preamble

YUP, that's right...the RACH preamble is longer than a timeslot, the AICH preamble is also longer than a timeslot.

Each preamble is of length 4096 chips and consists of 256 repetitions of a signature of length 16 chips. There are a maximum of 16 available signatures. The set of available signatures is indicated by the SIB5 message, and the UE uses the ASC (0-7) to determine the subset of that set and access slot to use. The UE selects the scrambling code number by adding the code number of the downlink primary scrambling code and the preamble scrambling code number (0-15) from SIB5. The same scrambling code is used for the message part, but with a code offset.

Typically the RACH preamble detection and AICH response is done solely in the physical layer since there is no information or handling needed from the higher layers. The physical layer simply detects a RACH preamble and echos a response either 7680 or 12800 chips after the arrival of the RACH preamble.

RACH Message Part

The 10 ms message part radio frame is split into 15 slots, each of length Tslot = 2560 chips. Each slot consists of two parts, a data part to which the RACH transport channel is mapped and a control part that carries Layer 1 control information. The data and control parts are transmitted in parallel. A 10 ms message part consists of one message part radio frame, while a 20 ms message part consists of two consecutive 10 ms message part radio frames. The message part length is equal to the Transmission Time Interval of the RACH Transport channel in use. This TTI length is configured by higher layers.

The data part consists of 10*2k bits, where k=0,1,2,3. This corresponds to a spreading factor of 256, 128, 64, and 32 respectively for the message data part.

The control part consists of 8 known pilot bits to support channel estimation for coherent detection and 2 TFCI bits. This corresponds to a spreading factor of 256 for the message control part. The pilot bit pattern is described in table 8. The total number of TFCI bits in the random-access message is 15*2 = 30. The TFCI of a radio frame indicates the transport format of the RACH transport channel mapped to the simultaneously transmitted message part radio frame. In case of a 20 ms PRACH message part, the TFCI is repeated in the second radio frame.

More details