Transcript
LONG TERM EVOLUTION (LTE)
23.1 RRC CONNECTION ESTABLISHMENT
.
RRC connection establishment is used to make the transition from RRC Idle mode to RRC Connected mode. UE must
make the transition to RRC Connected mode before transferring any application data, or completing any signalling
procedures
.
The RRC connection establishment procedure is always initiated by the UE but can be triggered by either the UE or the
network. For example, the UE triggers RRC connection establishment if the end-user starts an application to browse the
internet, or to send an email. Similarly, the UE triggers RRC connection establishment if the UE moves into a new
Tracking Area and has to complete the Tracking Area Update signalling procedure. The network triggers the RRC
connection establishment procedure by sending a Paging message. This could be used to allow the delivery of an incoming
SMS or notification of an incoming voice call
.
RRC connection establishment for LTE is relatively simple compared to RRC connection establishment for UMTS. The
UMTS procedure requires NBAP and ALCAP signalling across the Iub interface between the Node B and RNC. These
signalling protocols are used to setup a radio link and new transport connection. The flat network architecture for LTE
removes the requirement for these signalling procedures
.
In the case of LTE, the initial Non-Access Stratum (NAS) message is transferred as part of the RRC connection
establishment procedure. In the case of UMTS, the initial NAS message is transferred after the RRC connection
establishment procedure. The approach used by LTE helps to reduce connection establishment delay
.
RRC connection establishment configures Signalling Radio Bearer (SRB) 1 and allows subsequent signalling to use the
Dedicated Control Channel (DCCH) rather than the Common Control Channel (CCCH) used by SRB 0
.
The signalling for RRC connection establishment is shown in Figure 107. The entire procedure is completed using only
RRC signalling. A 3-way handshake is used to move the UE into RRC connected mode
eNod
eNodeNode B
e Be B
UE
UEUE
RRC Connection Request / SRB 0 / CCCH / UL-SCH / PUSCH
RRC Connection Setup / SRB 0 / CCCH / DL-SCH / PDSCH
RRC Connection Setup Complete / SRB 1 / DCCH / UL-SCH / PUSCH
Figure 107 . Signalling for RRC connection establishment
.
The RRC Connection Request message is sent as part of the Random Access procedure. It corresponds to the initial Layer
3 message shown in Figure 84 (section 21.1). It is transferred using SRB 0 on the Common Control Channel (CCCH)
because neither SRB 1 nor a Dedicated Control Channel (DCCH) have been setup at this point. The uplink Resource Block
allocation for the RRC Connection Request message is signalled within the Random Access Response message
.
The content of the RRC Connection Request message is shown in Table 130. It includes a UE identity and an
establishment cause. There is no scope for the UE to report any measurements within the RRC Connection Request
message. The UMTS version of the RRC Connection Request message allows the UE to report CPICH measurements
which can subsequently be used for downlink open loop power control calculations
.
The UE identity is signalled using the SAE Temporary Mobile Subscriber Identity (S-TMSI) if the UE is registered with
the Tracking Area to which the current cell belongs. Otherwise, the UE selects a random number in the range from 0 to 240
-1 to represent the UE identity. The S-TMSI is described in section 26.3.3
www.lte-bullets.com
IN BULLETS
Information Elements
UE Identity CHOICE
S-TMSI
Random Value
Establishment Cause CHOICE
Emergency
High Priority Access
Mobile Terminating Access
Mobile Originating Signalling
Mobile Originating Data
Table 130 . Content of RRC Connection Request message
.
The establishment cause within the RRC Connection Request message is determined by the Non-Access Stratum (NAS)
procedure for which the connection is being established. The relationship between establishment cause and NAS procedure
is specified by 3GPP TS 24.301. This relationship is presented in Table 131. In all cases, the RRC establishment cause is
set to ‘High Priority Access’ if the UE uses Access Class (AC) 11 to 15. The list of establishment causes is significantly
shorter than the list used by UMTS
NAS Procedure RRC Establishment Cause
Attach Mobile Originating Signalling
Detach
Tracking Area Update
Service Request User plane radio resources request Mobile Originating Data
Uplink signalling resources request
Paging response for PS core network domain Mobile Terminating Access
Extended Service Request Mobile originating CS fallback Mobile Originating Data
Mobile terminating CS fallback Mobile Terminating Access
Mobile originating CS fallback emergency call Emergency
Table 131 . Relationship between higher layer establishment cause and RRC establishment cause
.
The UE starts the T300 timer after transmitting the RRC Connection Request message. The value of T300 is broadcast
within SIB 2. UMTS uses T300 in combination with N300 to manage re-transmissions of the RRC Connection Request
message. LTE does not have an N300 parameter and the RRC Connection Request message is sent only once per
establishment procedure. LTE uses the T300 timer to define how long the UE waits for a response to the RRC Connection
Request message. The establishment procedure fails if T300 expires before receiving an RRC Connection Setup message.
The procedure also fails if the UE completes a cell re-selection prior to receiving the RRC Connection Setup message
.
Random access contention can occur after sending the RRC Connection Request message. Section 21.1 explains that
contention occurs when multiple UE select the same subframe and preamble sequence for PRACH transmission.
Contention requires the UE to repeat transmission of the PRACH preamble and the subsequent RRC Connection Request
message. This increases the delay associated with connection establishment but does not cause the overall procedure to fail
unless the maximum number of preamble transmissions has been reached
.
Assuming that random access contention does not occur, the UE proceeds to wait for an RRC Connection Setup message
from the eNode B. The UE has successfully completed the random access procedure so has been allocated a C-RNTI
(signalled within the random access response message). The UE monitors the PDCCH for a downlink allocation addressed
to its C-RNTI. The PDCCH specifies the set of PDSCH Resource Blocks used to transfer the RRC Connection Setup
message. The RRC Connection Setup message is transferred using SRB 0 on the CCCH
.
The RRC Connection Setup message contains configuration information for SRB 1. This allows subsequent signalling to
use the DCCH logical channel. SRB 2 is always configured after security activation so the RRC Connection Setup
message does not include any information regarding SRB 2. The eNode B can instruct the UE to apply a default
configuration for SRB 1, or it can instruct the UE to apply a specific configuration.
www.lte-bullets.com
LONG TERM EVOLUTION (LTE)
.
The default configuration for SRB 1 is presented in Table 132. This default configuration has been specified by 3GPP
within TS 36.331. Using the default configuration helps to reduce the signalling requirement. The default configuration for
SRB 2 is also presented in Table 132 for information. SRB 2 has a lower priority than SRB 1, i.e. a value of 3 represents a
lower priority than a value of 1. Both SRB 1 and 2 always use acknowledged mode RLC
SRB 1 SRB 2
RLC
Configuration
Uplink Poll Retransmission Timer 45 45
Poll PDU Infinity Infinity
Poll Byte Infinity Infinity
Max Retransmission Threshold 4 4
Downlink Re-ordering Timer 35 35
Status Prohibit Timer 0 0
Logical Channel
Configuration
Priority 1 3
Prioritised Bit Rate Infinity Infinity
Bucket Size Duration N/A N/A
Logical Channel Group 0 0
Table 132 . Default configurations for SRB 1 and SRB 2
.
The RRC Connection Setup message can also define configuration information for the PDSCH, PUCCH and PUSCH
physical channels. It can also include information regarding uplink power control, CQI reporting, the Sounding Reference
Signal, antenna configuration and scheduling requests
.
Upon receiving an RRC Connection Setup message, the UE stops the T300 timer and makes the transition to RRC
Connected mode. The UE then proceeds to complete the procedure by sending an RRC Connection Setup Complete
message. The content of the RRC Connection Setup Complete message is shown in Table 133
Information Elements
RRC Transaction Identifier (0 to 3)
Selected PLMN Identity (1 to 6)
Registered MME PLMN Identity
MMEGI
MMEC
Dedicated NAS Information
Table 133 . Content of RRC Connection Setup Complete message
.
The Transaction Identifier, combined with the message type, identifies the RRC procedure with the UE
.
The Selected PLMN Identity defines a pointer to a PLMN listed within SIB1, i.e. UE select the PLMN to which they want
to connect when a cell belongs to more than a single PLMN
.
The Registered MME information is optional, and is included when available. It becomes available after a UE has
registered with an MME. The MME is identified by its Globally Unique MME Identity (GUMMEI) which is a
concatenation of the PLMN identity, MME Group Identity (MMEGI) and MME Code (MMEC). The MMEC identifies the
MME within its group
.
The UE also includes its initial Non-Access Stratum (NAS) message within the RRC Connection Setup Complete message.
NAS messages are specified within 3GPP TS 24.301. As indicated within Table 131, the NAS message could be an
Attach, Detach, Tracking Area Update, Service Request or Extended Service Request message
.
The eNode B extracts the NAS message from the RRC Connection Setup Complete message and forwards it to an MME
using the S1 Application Protocol (S1-AP) Initial UE Message. Forwarding this message does not form part of the RRC
establishment procedure but is described within this section for completeness
.
The content of the S1-AP Initial UE Message is shown in Table 134. The eNode B sends this message to the appropriate
MME based upon its NAS Node Selection Function (NNSF). In the case of a Service Request, the S-TMSI included within
www.lte-bullets.com
IN BULLETS
the RRC Connection Request is used to identify the appropriate MME (S-TMSI includes the MMEC). In the case of an
Attach or Tracking Area Update, the eNode B uses the GUMMEI included within the RRC Connection Setup Complete
message. The eNode B is free to select an MME when the UE does not have an S-TMSI nor GUMMEI
Information Elements Presence
eNode B UE S1-AP Identity Mandatory
NAS PDU Mandatory
Tracking Area Identity (TAI) Mandatory
E-UTRAN Cell Global Identity (CGI) Mandatory
S-TMSI Optional
CSG Identity Optional
RRC Establishment Cause Mandatory
Globally Unique MME Identity (GUMMEI) Optional
Table 134 . Content of S1 Application Protocol (S1-AP) Initial UE Message
.
The eNode B allocates the eNode B UE S1-AP Identity to allow the eNode B to identify the UE within S1 signalling
procedures. The MME UE S1-AP Identity (not included within the Initial UE Message) allows the MME to identify the
UE within S1 signalling procedures
.
Figure 108 illustrates the signalling associated with the RRC connection establishment procedure when the eNode B
rejects the RRC Connection Request. The reject message is returned to the UE using SRB 0 on the CCCH logical channel.
The eNode B may reject the connection establishment request as a result of congestion
eN
eNeNod
odode B
e Be B
UE
UEUE
RRC Connection Request / SRB 0 / CCCH / UL-SCH / PUSCH
RRC Connection Reject / SRB 0 / CCCH / DL-
--SCH / PDSCH
Figure 108 . Signalling for rejected RRC connection establishment
.
The content of the RRC Connection Reject message is presented in Table 135. The message only includes a wait time.
This is in contrast to the equivalent UMTS message which also includes a rejection cause, although the UMTS rejection
cause can only be defined as congestion or unspecified The UMTS message can also include redirection information to
direct the UE towards another RF carrier, or Radio Access Technology (RAT)
Information Elements
Wait Time (0 to 16 seconds)
Table 135 . Content of RRC Connection Reject message
.
Upon receiving an RRC Connection Reject message, the UE starts the T302 timer with its value set equal to the wait time.
Access Class barring for mobile originating calls, mobile originating signalling and mobile terminating access is applied
until T302 expires, i.e. the UE is not allowed to send another RRC Connection Request for those connection types, and to
the same cell, until T302 expires. T302 is stopped if the UE completes cell reselection. In that case, the UE is permitted to
send an RRC Connection Request to the new cell
.
In contrast to UMTS, LTE requires the higher layers to initiate a new connection establishment procedure after the UE
receives an RRC Connection Reject message. UMTS allows the RRC Connection Request message to be repeated from
the RRC layer, based upon the value of N300
www.lte-bullets.com
RRC Connection 되어있는 UE가 eNB나 상위 Layer로 부터 신호가 없을 때
어느시간이 지나면 RRC idle이 되나요?
규격상의 특정 시간이 정의 되어있나요??
(RRC connected --> RRC idle)
제가 알기로는 규격상 정의되어 있는 시간은 없으며, 사업자가 적당한 시간을 설정하는걸로 알고 있습니다.
RRC-Connected 상태에서 eNB가 단말이 일정시간동안 (예를들면 10초) 메시지가 없으면
UE Context Release Request (Cause=user inactivity)를 MME에게 전송하여 S1 Release를 시도합니다.
참고삼아 국내 사업자의 경우 약 3~5초 정도로 설정해서 쓰고 있는 것으로 알고 있습니다.
지나가다, 시간적인 여유가 있어, 답글 남깁니다. 질의하신 내용은 UE Inactivity timer 기능이며, 이 기능을 이용하여, RRC Connection된 후에 설정해 놓은 임의의 일정시간 동안,
신호가 없을때신호와 상관없이, UE가 아무런 행동을 하지않아 서로 오고가는 Traiffic이 없을때, eNB에서 MME로 UE-Context release request를 하게 되고, 단말에서는 UE Context release complete 뒤에 RRC Connection release되어, Inactive mode(*idle) 로 바뀌게 하는 기능 입니다. 해당 관련 parameter의 range는 앞서 언급하신 것과 같이,3GPP-Spec에 명확하게 정의되어 있지않으므로(TS-23.401에서 관련된 설명이 나오기는 하나, 부족함) 각 vendor사에 정의된 range 및 default value가 상이합니다. 상세하게 언급해드리지는 못하지만, 대부분의 vendor가 수십초로 default 설정되어 있었으며, 구축 완료후 Traffic-Volume이 상당히 증가된뒤에 설정된 default 값이 품질에 영향을 주어, 국내/국외 vendor 나 사업자 구분없이 대부분의 global market에서 약10초 정도로 변경하여 사용하였습니다. 실례지만, 3~5초 면 상당히 짧은 시간인것 같은데, 10초에 비교하여, 짧은 시간으로 불필요한 자원을 더욱 효율적으로 제어/관리하고, UE-Power consumption등의 여러가지 benefit 이 있는 것은 이해하고 있습니다. 실제로 국내에서 해당 값을 사용하고 있다면, 어느 사업자 및 어느 vendor에서 그렇게 사용하고 있는 지 여쭤봐도 실례가 안될까요? 해당 파라미터는 eNB 혹은 ePC(NAS)에서도 Trigger 할수 있는 것으로 알고 있고, 언급하신 3~5초는 eNB에서 제어하는 UE-Inactivitiy timer로 가정한다고 했을때, 해당 inactivity timer trigger되는 조건이 해당 Vendor에서는, 모든 SRB and DRB을 포함하는 것인가요? 그리고, 호가 해제된 뒤에도, S1-Paging clycle에 의해서, ue가 paging 수신이후에 자동으로 RRC Connection request 시도 하는 경우도 있고,..S1 signaling과도 연관되어 너무 짧은 시간이면 Traffic volumn이 높은 지역의 eNB~MME에도 부하 생길것 같습니다. 혹시, Connected mode DRX Cycle 및 DRX-Inactivity timer는 어떻게 설정을 하셨는지요? 실제 User-experienced quality 기준으로 품질에 아무런 악영향이 없나 봅니다.참고로, UE-inactivity timer관련하여, 논지에서 조금 벗어나긴 하지만, DRX-inactivity timer도 존재합니다. DRX같은 경우 Long/Short-DRX로 나누어 지며, Short DRX 같은 경우, 설정된 DRX-inactivity timer 완료뒤에 Short DRX Cycle timer가 별도 운용 되며, DRX-inactivity timer의 경우, DL/UL의 자원할당이후에 PDCCH-Subframe을 연속적으로 모니터링 한뒤에 해당 timer을 Control하고 있습니다.
곽건섭님이 추정하신 대로 제가 언급한 3~5초의 시간은 단말이 아닌
eNB에서의 UE Inactivity Timer 값을 의미하고 DRB를 대상으로 합니다. 제 설명이 좀 짧았네요.
제가 알기로 거의(?) 모든 RRC 관리는 단말이 아닌 eNB쪽에서 주도를 하고
사업자 튜닝 파라메터의 하나 (Paging 부하 vs 라디오 효율성) 로 보고 있는 것으로 압니다.
그리고 3~5초 정도의 IDLE Timer면 시간이면 정상적인 UDP 스트리밍이나 TCP 스트리밍/웹브라우징 트래픽에
대해 QoE 측면의 저하가 발생하지는 않을 것입니다.
그 외 사항에 대해서는 제가 사업자/주 분야가 아니라서 의견을 드릴 수는 없을 것 같네요.
명쾌한 답변은 아니지만, 도움이 되었습니다. 감사합니다. 제가 궁금 했던 부분은 앞선 언급해 드렸던 것 과
같이,
1) eNB에서 Trigger하는 UE-inactivity timer 값인지 / NAS UE-Inactivity timer인지?
-> NAS UE Inactivity timer 의 default 값은 eNB에서 Trigger하는 UE-Inactivity timer에 비교하여, 당연히 짧을
수 밖에 없으며, 대부분의 vendor가 3~4초로 사용 하고 있는 것으로 알고 있기 때문입니다.
2) 언급 하신데로 eNB에서 Trigger하는 값이라면, 특정 A vendor는 10초 / B vendor는 3~4초....
-> B vendor에서는 아무런 리스크가 없고, 개선사항만 있다고 가정했을때, eNB자체 의 RRM 블럭의 Capability
가 뛰어나거나, 혹은 다른 연관성이 있는 parameter..예를 들어,CDRX 사용여부..사용하고 있다면,
어떻게 운용되어 지고 있는 지가 궁금했었는데, 아무튼 성실하게 답변 해 주실려고 노력 하신 점
감사드립니다.
보다, 정확한 정보 전달을 위하여, 추가 답변 드립니다. 언급드렸던 것 과 같이, 해당기능은 eNB에서 제어가능한 ue-inactive 관련 parameter는 무선자원을 제어하고, 관리하는 RRM 블럭과 연관성이 있으며, 관련규격의 "RRM-Config information element" 에서 아래의 Range값이 정의 되어 있으나, 실제 각기 벤더사에서는 1) eNB에서 제어 가능한 ue-inactivitity timer 와 2) Corenetwork에서 NAS(None Access Stratum) signaling을 통하여 제어 가능한, ue inactivity timer 의 range 및 default 값이 벤더사 마다, 각기 상이합니다.
ue-InactiveTime ENUMERATED {
s1, s2, s3, s5, s7, s10, s15, s20,
s25, s30, s40, s50, min1, min1s20c, min1s40,
min2, min2s30, min3, min3s30, min4, min5, min6,
min7, min8, min9, min10, min12, min14, min17, min20,
min24, min28, min33, min38, min44, min50, hr1,
hr1min30, hr2, hr2min30, hr3, hr3min30, hr4, hr5, hr6,
hr8, hr10, hr13, hr16, hr20, day1, day1hr12, day2,
day2hr12, day3, day4, day5, day7, day10, day14, day19,
day24, day30, dayMoreThan30} OPTIONAL,