| 리포트 | 기술문서 | 테크-블로그 | 원샷 갤러리 | 링크드인 | 스폰서 컨텐츠 | 네트워크/통신 뉴스 | 인터넷자료실 | 자유게시판    한국 ICT 기업 총람 |

제품 검색

|

통신 방송 통계

 
 
 
섹션 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/UHD IoT SDN/NFV Wi-Fi Video Streaming KT SK Telecom LG U+ OTT Network Protocol CDN YouTube Data Center
 

2023

5G 특화망

포탈

Private 5G/이음 5G

 포탈홈

  넷매니아즈 5G 특화망 분석글 (128)   5G 특화망 4가지 구축모델   산업계 5G 응용   산업분야별 5G 특화망 활용사례  [5G 특화망 벤더Samsung | HFR | Nokia | more
 

해외

  국가별 사설5G 주파수 [국가별 구축현황] 일본 | 독일 | 미국 | 프랑스 | 영국  [사설5G 사업자] Verizon | AT&T | DT | Telefonica | AWS | Microsoft | NTT동일본 | NTT Com    
 

국내

  5G 특화망 뉴스 | 국내 5G 특화망 구축 현황 | 국내 5G 특화망사업자 현황 (19개사) | 국내 자가구축사례 일람 | 국내 특화망 실증사업사례 일람 | 5G 특화망 정책
 
 

[5G 특화망 구축 사례] 한국식품산업클러스터 | 반월시화산단 삼성서울병원 | 롯데월드 | 한국수력원자력 | 해군본부 | 한국전력공사 | more  [이통사] KT

 
 
스폰서채널 |

 HFR의 5G 특화망 솔루션 (my5G)  Updated   | HFR 5G 특화망 뉴스HFR my5G 자료

  스폰서채널 서비스란?
NETMANIAS
기술자료실
View All (861)
4G (2) 4G Evolution (1) 5G (49) 5G 특화망 (10) 5g (1) 802.11 (1) 802.1X (1) ALTO (1) ANDSF (1) AT&T (2) Acceleration (1) Adobe HDS (3) Akamai (6) Amazon (3) Apple HLS (4) Authentication (1) BRAS (2) BT (1) Backbone (4) Backhaul (12) BitTorrent (1) Broadcasting (3) C-RAN (13) C-RAN/Fronthaul (12) CCN (4) CDN (52) CDNi (1) COLT (1) CORD (1) CPRI (2) Cache Control (1) Caching (5) Carrier Cloud (2) Carrier Ethernet (9) Channel Zapping (4) China Mobile (1) China Telecom (1) Cloud (10) Cloudfront (1) DASH (2) DCA (1) DHCP (3) DNS (1) DSA (1) Data Center (7) Dynamic Web Acceleration (1) EDGE (1) EPC (5) Edge (1) Energy (1) Ericsson (5) Ethernet (8) FEO (2) Fairness (1) Fronthaul (5) GiGAtopia (1) Gigabit Internet (2) Global CDN (1) Google (5) HLS (1) HTTP (1) HTTP Adaptive Streaming (18) HTTP Progressive Download (3) HTTP Streaming (1) HetNet (1) Hot-Lining (1) Hotspot 2.0 (2) Huawei (3) ICN (4) IP (1) IP Allocation (1) IP Routing (8) IPTV (15) Intel (1) Internet (1) Interoperability (2) IoST (1) IoT (14) KT (22) LG U+ (3) LTE (70) LTE MAC (1) LTE-A (2) Licensed CDN (1) M2M (3) MEC (5) MPLS (25) MVNO (1) Market (4) Metro Ethernet (7) Microsoft (2) Migration (1) Mobile (4) Mobile Backhaul (1) Mobile Broadcasting (1) Mobile CDN (2) Mobile IP (1) Mobile IPTV (3) Mobile Video (1) Mobile Web Perormance (1) Mobility (1) Multi-Screen (7) Multicast (7) NFC (1) NFV (2) NTT Docomo (2) Netflix (6) Network Protocol (31) Network Recovery (3) OAM (6) OTT (31) Ofcom (1) Offloading (2) OpenFlow (1) Operator CDN (14) Orange (1) P2P (4) PCC (1) Page Speed (1) Private 5G (13) Programmable (1) Protocol (7) Pseudowire (1) QoS (5) Router (1) SCAN (1) SD-WAN (1) SDN (15) SDN/NFV (15) SK Telecom (22) SON (1) SaMOG (1) Samsung (2) Security (6) Service Overlay (1) Silverlight (4) Small Cell (3) Smart Cell (1) Smart Grid (2) Smart Network (2) Supper Cell (1) Telefonica (1) Telstra (1) Terms (1) Traffic (2) Traffic Engineering (1) Transcoding (3) Transparent Cache (2) Transparent Caching (14) VLAN (2) VPLS (2) VPN (9) VRF (2) Vendor Product (2) Verizon (2) Video Optimization (4) Video Pacing (1) Video Streaming (14) Virtual Private Cloud (1) Virtualization (3) White Box (1) Wholesale CDN (4) Wi-Fi (13) WiBro(WiMAX) (4) Wireless Operator (5) YouTube (4) eMBMS (4) eNB (1) 망이용대가 (1) 망중립성 (1) 스마트 노드 (1) 이음 5G (3)
View All (332)
3GPP (1) 3GSM (1) 4G Americas (2) 5G PPP (1) ALU (16) AT&T (5) AWS (1) AWS Whitepaper (2) Adobe (1) Agilent (1) Akamai (7) Alcatel (1) Altman Vilandrie (1) Amazon (3) Aruba (1) BT (7) BTI (2) BTI/Juniper (1) Belgacom (1) Blaze (1) Brigewater Systems (1) Broadband Forum (1) Broadcom (1) Bytemobile (1) CDNetworks (4) CMCC (1) COLT (1) Cambridge Broadband Networks (1) Capacity Magazine (1) China Mobile (1) China Unicom (1) Chris Johnson (NSN) (1) Cisco (36) Colt (1) Comcast (2) Core Analysis (1) Current Analysis (1) DCIA (1) DT (1) Deepfield (1) Digital Society (1) ETRI (1) Edgeware (1) Ericsson (14) EventHelix (1) FT (1) Fernando Ramos (1) Freescale (2) GATECH (1) GSA (3) GSMA (2) Google (3) HP (1) Heavy Reading (2) Huawei (4) IDC (1) ITC (1) ITU (2) Intel (3) Jet-Stream (1) Juniper (6) KAIST (1) KBS (1) KISDI (1) KPN (1) KT (39) Kul Cloud (1) LG (1) LG U+ (5) Lightreading (1) MEF (1) MSF (2) Meru (1) Microsoft (4) NGMN (2) NGMN Alliance (1) NHN (1) NSN (4) NTT (4) NTT DoCoMo (1) Netflix (2) Netmanias (4) Nokia (1) Nova Datacom (1) OCEAN (1) Octoshape (1) Openwave (1) Orange (1) PSCR (1) PT (1) PeerApp (1) QCT (Quanta Cloud Technology, 대만) (1) Qualcomm (4) RGB Networks (1) RTAN TOMAYKO (1) Redback (1) Rohde & Schwarz (1) Ruckus Wireless (2) SK Telecom (21) SKT (8) STC (1) Samsung (5) Sandvine (1) SemiAccurate (1) Skyfire (1) Skytide (2) Softbank Mobile (1) Sprint (1) Stoke (1) Strangeloop (1) Swisscom (1) TI (1) TKK (1) Takehiro Nakamura, NTT Docomo (1) Telesystem (1) Telstra (1) Total Telecom (1) Univ. of Agder (1) University of Minnesota (1) Van Jacobson (1) VeEX (1) Velocloud (1) Verizon (4) Vodafone (1) WWP (1) Wiley (1) Yale (1) nLayer (1) tomshardware (1) 스프링웨이브 (1)
박재현 08/08/2011
By Chris Johnson (NSN)

RRC connection 설정 절차가 궁금하면 읽어보세요. 설명이 자세히 되어 있습니다..

S.H.W 2014-08-19 14:22:11

RRC Connection 되어있는 UE가 eNB나 상위 Layer로 부터 신호가 없을 때

어느시간이 지나면 RRC idle이 되나요?

규격상의 특정 시간이 정의 되어있나요??

(RRC connected --> RRC idle)

Yoo 2014-08-20 13:27:49

제가 알기로는 규격상 정의되어 있는 시간은 없으며, 사업자가 적당한 시간을 설정하는걸로 알고 있습니다.

 

RRC-Connected 상태에서 eNB가 단말이 일정시간동안 (예를들면 10초) 메시지가 없으면

UE Context Release Request (Cause=user inactivity)를 MME에게 전송하여 S1 Release를 시도합니다. 

버너 2014-08-20 18:05:57

참고삼아 국내 사업자의 경우 약 3~5초 정도로 설정해서 쓰고 있는 것으로 알고 있습니다. 

곽권섭 2014-08-22 15:48:46

지나가다, 시간적인 여유가 있어, 답글 남깁니다. 질의하신 내용은 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하고 있습니다.

버너 2014-08-28 11:09:41

곽건섭님이 추정하신 대로 제가 언급한 3~5초의 시간은 단말이 아닌

eNB에서의 UE Inactivity Timer 값을 의미하고 DRB를 대상으로 합니다. 제 설명이 좀 짧았네요.

 

제가 알기로 거의(?) 모든 RRC 관리는 단말이 아닌 eNB쪽에서 주도를 하고

사업자 튜닝 파라메터의 하나 (Paging 부하 vs 라디오 효율성) 로 보고 있는 것으로 압니다.

그리고 3~5초 정도의 IDLE Timer면 시간이면 정상적인 UDP 스트리밍이나 TCP 스트리밍/웹브라우징 트래픽에

대해 QoE 측면의 저하가 발생하지는 않을 것입니다.

 

그 외 사항에 대해서는 제가 사업자/주 분야가 아니라서 의견을 드릴 수는 없을 것 같네요. 

곽권섭 2014-08-28 16:07:09

명쾌한 답변은 아니지만, 도움이 되었습니다. 감사합니다. 제가 궁금 했던 부분은 앞선 언급해 드렸던 것 과

같이, 

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 사용여부..사용하고 있다면,

       어떻게 운용되어 지고 있는 지가 궁금했었는데, 아무튼 성실하게 답변 해 주실려고 노력 하신 점 

       감사드립니다.

곽권섭 2014-09-08 15:33:45

보다, 정확한 정보 전달을 위하여, 추가 답변 드립니다. 언급드렸던 것 과 같이, 해당기능은 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,

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
1
비밀번호 확인
코멘트 작성시 등록하신 비밀번호를 입력하여주세요.
비밀번호