DOCSLIB.ORG

(19) United States (12) Patent Application Publication (10) Pub

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
(19) United States (12) Patent Application Publication (10) Pub US 20140071868A1 (19) United States (12) Patent Application Publication (10) Pub. No.: US 2014/0071868 A1 Bergquist et al. (43) Pub. Date: Mar. 13, 2014 (54) APPARATUSES AND METHODS FOR Publication Classi?cation MANAGING PENDING HARQ RETRANSMISSIONS (51) Int. Cl. H04W 76/04 (2006.01) (71) Applicants:Gunnar Bergquist, Kista (SE); Riikka H04L 1/18 (2006.01) Susitaival, Helsinki (Fl); Anders Ohlsson, Jarfalla (SE); Mikael (52) US. Cl. Wittberg, Uppsala (SE) CPC ......... .. H04W 76/048 (2013.01); H04L 1/1803 (2013.01) (72) Inventors: Gunnar Bergquist, Kista (SE); Riikka USPC ......................................... .. 370/311; 370/328 Susitaival, Helsinki (Fl); Anders Ohlsson, Jarfalla (SE); Mikael Wittberg, Uppsala (SE) (57) ABSTRACT (73) Assignee: Telefonaktiebolaget L M Ericsson (publ), Stockholm (SE) Methods and systems present solutions to, for example, the (21) Appl. No .: 13/825,462 problem of unnecessary preparedness for suspended retrans missions in the user equipment (UE) Which contributes to (22) PCT Filed: Nov. 9, 2012 poWer drain in the device battery. One method for monitoring a Physical DoWnlink Control Channel (PDCCH) for adaptive PCT No.: PCT/SE2012/051225 (86) retransmission grants in a radio communication system § 371 (0X1), includes: monitoring, by a user equipment (U E), the PDCCH (2), (4) Date: Mar. 21, 2013 for adaptive retransmission grants; receiving, by the UE, a Related US. Application Data hybrid automatic repeat request (HARQ) acknowledge (ACK) message, and ceasing, by the UE, to monitor the (60) Provisional application No. 61/646,757, ?led on May PDCCH for adaptive retransmission grants after receipt of the 14, 2012. HARQ ACK message. -------- -- RADIO BEARERS BCCH PCCH SEGM. 24 28 ARQ ETC f / / ------------ --+ --- SCHEDULING / PRIORITY HANDLING 2. 2. TRANSPORT CHANNELS \ll Patent Application Publication Mar. 13, 2014 Sheet 1 0f 15 US 2014/0071868 A1 m’5218m:80s "ME\\>E..E 0% 0% {02__WKs\a\ 250mm218mm58mm25mm ..++a.... :\s\\a20mm.295.230,5% me\2\ ml 0%:0%m/a/ m0:20:3012 was‘gwz?maé5:925:52‘32 ml $2725502........................ ............ ..... 2"$22?222%........................................--.............. .............. fzwmémmoaé.....................................L \mé@2225ED552585 N Patent Application Publication Mar. 13, 2014 Sheet 2 0f 15 US 2014/0071868 A1 ---- LOGICALCHANNELS SCHEDULING / PRIORITY HANDLING \16 \ MULTIPLEXING / HARQ -------------- --<{>--------—--------TRANSPORTCHANNELS FIG. 2 Patent Application Publication Mar. 13, 2014 Sheet 3 0f 15 US 2014/0071868 A1 AlxmamomEZDEOQQQIV 50BxmoAllliv a m.0_H_ AIZOEEDQ201' 18% Patent Application Publication Mar. 13, 2014 Sheet 4 0f 15 US 2014/0071868 A1 $3032.28 V E05g 025“650 m5éa a 56% w0_u_. é 50$Em 29523200552m Patent Application Publication Mar. 13, 2014 Sheet 5 0f 15 US 2014/0071868 A1 M Om g/ was20%a / mm E:\> Mv wasE5 iM 50%E>_5<z_ M30502o.“V95 AIZOEEDQzo -182222%m:........ Patent Application Publication Mar. 13, 2014 Sheet 6 0f 15 US 2014/0071868 A1 @m/ XE kzéo //A 8/ 21 § //A 92: v2 @.QI XE EEQ 35% wmw EEO .2300£553 E300mz/Elmzw E38mzémmzw m2:mag/32a 20:2 Patent Application Publication Mar. 13, 2014 Sheet 7 0f 15 US 2014/0071868 A1 c2szmwNEQEDOEEEa EE amma588E253 EE mas2zEaEDSMEEa EE OZ$2fOP@0213? ///7//MEEEEQ Fo_Qwwmoomémé /////,7//AEEEEQ 0wcFOmwwQEOE 222E0EE9E0 //AMEEEEQ/ PEQEEO20:2E2% PE2%76:2V22% E32% E:2% E:E@ E E E Patent Application Publication Mar. 13, 2014 Sheet 8 0f 15 US 2014/0071868 A1 S S 2% i /// 0%: /// w.QI K 3 5:00mzémmpw .2300mzémmaw E300mzélmzm 22% Patent Application Publication Mar. 13, 2014 Sheet 9 0f 15 US 2014/0071868 A1 zmNwoEDGE/Emma %a2% a@Nahzno?zémma %Va2% az2sahzzoomgémma %a2% 0%:5% 22% 0%:S% 222 a;5% 5Q %/£52556 Patent Application Publication Mar. 13, 2014 Sheet 10 0f 15 US 2014/0071868 A1 55555555555555?i--...........-. 555555 25saNm55855555550, 555N55mamm555558555555 555aN55mmms5555585555555 555 .55 .-5.5555<.5.%55.m.5--1..................................................................- 555 .55 5/5515.55,55 ///A555555555 2.@I 5555555555055 2555555255555555555555 57-55555 55550555555 5%/555557- 5555 //555555555 555555555555.............- //555552555 Patent Application Publication Mar. 13, 2014 Sheet 11 0f 15 US 2014/0071868 A1 RECEIVING, BY THE USER EQUIPMENT, AN ADAPTIVE RETRANSMISSION GRANT CONTROL MESSAGE WHICH / I00 INSTRUCTS THE USER EQUIPMENT HOW TO MONITOR THE PDCCH FOR ADAPTIVE RETRANSMISSION GRANTS II RECEIVING, BYAUSER EQU|PMENT,AHYBR|D 102 AUTOMATIC REPEAT REQUEST (HARQ) ACKNOWLEDGE / (ACK) MESSAGE, AND V SELECTIVELY (a) MONITORING THE PDCCH, (b) POSTPONING MONITORING OF THE PDCCH OR (0) HALTING MONITORING OF THEPDCCH, BY THE 104 USER EQUIPMENT, AFTER RECEIPT OF THE HARQ / . ACK MESSAGE, IN AMANNER WHICH IS BASED ON THE ADAPTIVE RETRANSSQII/IESION GRANT CONTROL ME E. FIG. 11 Patent Application Publication Mar. 13, 2014 Sheet 12 0f 15 US 2014/0071868 A1 MONITORING, BYA USER EOUIPMENT(UE), THE PDCCH /-200 FOR ADAPTIVE RETRANSMISSION GRANTS II RECEIVING, BY THE DE, A HYBRID AUTOMATIC REPEAT REQUEST (HARQ) /202 ACKNOWLEDGE (ACK) MESSAGE V CEASING, BY THE UE, TO MONITOR THE PDCCH FOR ADAPTIVE /204 RETRANSMISSION GRANTS AFTER RECEIPT OF THE HARQ ACK MESSAGE FIG. 12 Patent Application Publication Mar. 13, 2014 Sheet 13 0f 15 US 2014/0071868 A1 TRANSMITTING, BY AN NETWORK NODE, A MESSAGE WHICH INSTRUCTS A 300 USER EQUIPMENT TO CEASE MONITORING THE PDCCH AFTER RECEIPT OF / A HYBRID AUTOMATIC REPEAT REQUEST (HARQ) ACKNOWLEDGE (ACK) MESSAGE FIG. 13 Patent Application Publication Mar. 13, 2014 Sheet 14 0f 15 US 2014/0071868 A1 /400 404\\ PROCESSING CIRCUITRY NETWORK /4oa /J:—— INTERFACE RADIO . MEMORY FIG. 14 Patent Application Publication Mar. 13, 2014 Sheet 15 0f 15 US 2014/0071868 A1 '98 RADIO CiRCUiTRY PROCESSING <1 504"\ CIRCUITRY - FIG. 15 US 2014/0071868 A1 Mar. 13, 2014 APPARATUSES AND METHODS FOR either sends a positive acknoWledgment (“ACK”) (data block MANAGING PENDING HARQ is received or decoded successfully) or a negative acknoWl RETRANSMISSIONS edgement (“NACK”) (data block is undecodable). The trans mitter responds to a NACK by re-transmitting the informa TECHNICAL FIELD tion. [0001] The present disclosure generally relates to appara [0007] HARQ is a stop-and-Wait protocol. Being a stop and-Wait protocol, (re)transmissions are restricted to occur at tuses and methods for radio communications and, more spe ci?cally, to Hybrid Automatic Repeat reQuest (HARQ) and knoWn time instants, in betWeen Which the sender stops and Discontinuous Reception (DRX) algorithms. Waits for ACK/NACK feedback from the receiver. As used herein, “feedback”, and particularly HARQ feedback, includes both feedback of a positive acknoWledgement BACKGROUND (“ACK”) and feedback of negative acknoWledgement [0002] In the last years, mobile devices have become ubiq (“NACK”). Thus, subsequent transmission of neW data can uitous, applications for these mobile devices have ?ooded the take place only after Waiting to receive ACK/NACK from the market, and clients’ expectations for omnipresent high qual receiving entity. In case an ACK is received a neW transmis ity service have challenged the netWork service providers. sion occurs, otherWise a retransmission occurs. This scheme Among other things, users expect services to be delivered can be improved by using multiple channels for supporting With high quality, and some services require high quality in HARQ service. The HARQ receiver must transmit either the radio communications in order to be perceived by users as ACK or NACK, still of course there is the possibility that the being delivered satisfactorily. Unfortunately, in a radio envi sender detects neither. This is referred to as detection of a ronment, there Will be situations Where some, e.g., data pack Discontinuous Transmission (DTX). There are tWo possible ets, are not received properly by a user’s equipment and, in reasons for a DTX detection to occur, either the data Was lost such cases, it may be necessary to retransmit those data pack or the forWard transmission Was lost and not detected by the ets in order to provide an appropriate level of service. receiver. [0003] The telecommunications industry has used the [0008] When the HARQ transmitter has reached the maxi Automatic Repeat reQuest (ARQ) layer 2 protocol for many mum number of retransmissions for a transport block Without years as a retransmission mechanism to ensure that data is getting an ACK, the HARQ transmitter Will stop transmitting sent reliably from one node to another. More recently, certain and let a higher layer ARQ take over, if any such higher layer standards, such as the Third Generation Partnership Project ARQ exists. Examples of such higher layers that engageARQ (3GPP) Long Term Evolution (LTE) standard, have taken are the Radio Link Control (RLC), 3GPP TS 36.322 V11.0.0 advantage of a Hybrid ARQ (HARQ) process to counteract (2012-09), and the Transmission Control Protocol (TCP), errors. See FIG. 1 and FIG. 2 for the illustrations of the Layer RFC 2581 (1999-04). 2 architecture used in LTE. [0009] The standards document 3GPP TS 36.300, Evolved [0004] FIG. 1 shoWs the Layer 2 architecture for doWnlink Universal Terrestrial Radio Access (E-UTRA) and Evolved (DL) 2 used in LTE and includes the Packet Data Conver Universal Terrestrial Radio Access NetWork (E-UTRAN); gence Protocol (PDCP) sublayer 4, the Radio Link Control Overall description; Stage 2, version 11.3.0, sub-clause 9.1 (RLC) sublayer 6 and the Medium Access Control (MAC) explains some of the principles of LTE HARQ used by 3GPP. sublayer 8. The PDCP layer 4 includes
Load more

Recommended publications
  • Technical Characteristics for a VHF Data Exchange System in the VHF Maritime Mobile Band
    Recommendation ITU-R M.2092-0 (10/2015) Technical characteristics for a VHF data exchange system in the VHF maritime mobile band M Series Mobile, radiodetermination, amateur and related satellite services ii Rec. ITU-R M.2092-0 Foreword The role of the Radiocommunication Sector is to ensure the rational, equitable, efficient and economical use of the radio- frequency spectrum by all radiocommunication services, including satellite services, and carry out studies without limit of frequency range on the basis of which Recommendations are adopted. The regulatory and policy functions of the Radiocommunication Sector are performed by World and Regional Radiocommunication Conferences and Radiocommunication Assemblies supported by Study Groups. Policy on Intellectual Property Right (IPR) ITU-R policy on IPR is described in the Common Patent Policy for ITU-T/ITU-R/ISO/IEC referenced in Annex 1 of Resolution ITU-R 1. Forms to be used for the submission of patent statements and licensing declarations by patent holders are available from http://www.itu.int/ITU-R/go/patents/en where the Guidelines for Implementation of the Common Patent Policy for ITU-T/ITU-R/ISO/IEC and the ITU-R patent information database can also be found. Series of ITU-R Recommendations (Also available online at http://www.itu.int/publ/R-REC/en) Series Title BO Satellite delivery BR Recording for production, archival and play-out; film for television BS Broadcasting service (sound) BT Broadcasting service (television) F Fixed service M Mobile, radiodetermination, amateur and related satellite services P Radiowave propagation RA Radio astronomy RS Remote sensing systems S Fixed-satellite service SA Space applications and meteorology SF Frequency sharing and coordination between fixed-satellite and fixed service systems SM Spectrum management SNG Satellite news gathering TF Time signals and frequency standards emissions V Vocabulary and related subjects Note: This ITU-R Recommendation was approved in English under the procedure detailed in Resolution ITU-R 1.
    [Show full text]
  • Flow Control and ARQ Media Access Physical
    Data Link Layer The Data Link layer can be further subdivided into: Computer Networks application 1. Logical Link Control (LLC): provides flow and error control transport • different link protocols may provide different services, e.g., Ethernet doesn’t provide reliable network delivery (error recovery) Lecture 26: 2. Media Access Control (MAC): framing and LLC MAC Flow Control and ARQ media access physical Link Layer Services Flow Control Flow Control: What is flow control? • pacing between adjacent sending and receiving nodes • receiver telling sender to slow down Error Control: Why do you need flow control? • errors caused by signal attenuation, noise • ARQ: receiver detects presence of errors and asks sender for retransmission Flow control protocols at data link layer (single hop): • FEC: receiver identifies and corrects bit error(s), • XON/XOFF without resorting to retransmission • Stop & Wait Protocol • Sliding Window Protocol Reliable delivery between adjacent nodes • seldom used on low bit error links (fiber, some twisted pair) Similar issues and mechanisms apply at the • plays an important role in wireless links with high error rates transport layer (end-to-end) • Q: why do we need both link-level and end-end reliability? XON/XOFF Stop and Wait (S&W) Protocol ! : propagation After sending a packet, sender must wait for delay SR acknowledgment (ACK) before sending the next packet sender receiver Sender Receiver S R round-trip Algorithm: time (rtt) t • S sends stream of data Time ! : propagation • R sends XOFF, S stops transmission pkt
    [Show full text]
  • Master's Thesis
    MASTER'S THESIS Analysis of UDP-based Reliable Transport using Network Emulation Andreas Vernersson 2015 Master of Science in Engineering Technology Computer Science and Engineering Luleå University of Technology Department of Computer Science, Electrical and Space Engineering Abstract The TCP protocol is the foundation of the Internet of yesterday and today. In most cases it simply works and is both robust and versatile. However, in recent years there has been a renewed interest in building new reliable transport protocols based on UDP to handle certain problems and situations better, such as head-of-line blocking and IP address changes. The first part of the thesis starts with a study of a few existing reliable UDP-based transport protocols, SCTP which can also be used natively on IP, QUIC and uTP, to see what they can offer and how they work, in terms of features and underlying mechanisms. The second part consists of performance and congestion tests of QUIC and uTP imple- mentations. The emulation framework Mininet was used to perform these tests using controllable network properties. While easy to get started with, a number of issues were found in Mininet that had to be resolved to improve the accuracy of emulation. The tests of QUIC have shown performance improvements since a similar test in 2013 by Connectify, while new tests have identified specific areas that might require further analysis such as QUIC’s fairness to TCP and performance impact of delay jitter. The tests of two different uTP implementations have shown that they are very similar, but also a few differences such as slow-start growth and back-off handling.
    [Show full text]
  • Chapter 5 Peer-To-Peer Protocols and Data Link Layer
    Chapter 5 Peer-to-Peer Protocols and Data Link Layer PART I: Peer-to-Peer Protocols Peer-to-Peer Protocols and Service Models ARQ Protocols and Reliable Data Transfer Flow Control Timing Recovery TCP Reliable Stream Service & Flow Control Chapter 5 Peer-to-Peer Protocols and Data Link Layer PART II: Data Link Controls Framing Point-to-Point Protocol High-Level Data Link Control Link Sharing Using Statistical Multiplexing Chapter Overview z Peer-to-Peer protocols: many protocols involve the interaction between two peers z Service Models are discussed & examples given z Detailed discussion of ARQ provides example of development of peer-to-peer protocols z Flow control, TCP reliable stream, and timing recovery z Data Link Layer z Framing z PPP & HDLC protocols z Statistical multiplexing for link sharing Chapter 5 Peer-to-Peer Protocols and Data Link Layer Peer-to-Peer Protocols and Service Models Peer-to-Peer Protocols zzz zzz z Peer-to-Peer processes execute layer-n protocol to provide service to n + 1 peer process n + 1 peer process layer-(n+1) z Layer-(n+1) peer calls SDU SDU layer-n and passes PDU Service Data Units n peer process n peer process (SDUs) for transfer z Layer-n peers exchange Protocol Data Units (PDUs) to effect transfer n – 1 peer process n – 1 peer process z Layer-n delivers SDUs to destination layer-(n+1) peer zzz zzz Service Models z The service model specifies the information transfer service layer-n provides to layer-(n+1) z The most important distinction is whether the service is: z Connection-oriented z Connectionless z Service model possible features: z Arbitrary message size or structure z Sequencing and Reliability z Timing, Pacing, and Flow control z Multiplexing z Privacy, integrity, and authentication Connection-Oriented Transfer Service z Connection Establishment z Connection must be established between layer-(n+1) peers z Layer-n protocol must: Set initial parameters, e.g.
    [Show full text]
  • Satellite and Terrestrial Network for 5G
    SaT5G (761413) D4.3 May 2020 Satellite and Terrestrial Network for 5G D4.3 Multi-link and Heterogeneous Transport - Analysis, Design and Proof of Concepts SaT5G (761413) D4.3 May 2020 Document History Version Date Modifications Source 0.1 28/06/18 Initial structure OA 0.8 17/10/18 Multi-Access state of the art and Multi-Access at 3GPP OA 0.85 1/11/19 QoS in Satcom TNO 0.9 10/11/19 MPTCP and MPQUIC BT 1.0 18/12/19 Prototypes, PEP and Standardization OA Topic ICT-07-2017 Project Title Satellite and Terrestrial Network for 5G Project Number 761413 Project Acronym SaT5G Contractual Delivery Date Aug 2019 (M27) Actual Delivery Date 30/12/2019 Contributing WP WP4.3 Project Start Date 01/06/2017 Project Duration 33 months Dissemination Level PU Editor OA Contributors SES, ADS, TNO, i2CAT SaT5G (761413) D4.3 May 2020 Name Organization Mamoutou Diarra OA Relja Djapic TNO M. (Miodrag) Djurica TNO Philip Eardley BT Thierry Masson OA Franck Messaoudi OA Luc Ottavj OA Boris Tiomela Jou ADS Simon Watts AVA Hamzeh Khalili I2CAT Ning Wang UoS SaT5G (761413) D4.3 May 2020 Table of Contents Table of Contents .................................................................................................................................. 4 List of Figures ....................................................................................................................................... 6 List of Tables ......................................................................................................................................... 7 List of Acronyms
    [Show full text]
  • Chapter 3: ARQ Protocols —Reference 1, Sections 2.1, 2.4, 2.6-2.9
    -1- Chapter 3: ARQ Protocols —Reference 1, sections 2.1, 2.4, 2.6-2.9 1. ARQ retransmission strategies Automatic Repeat reQuest - The receiverdetects a transmission unit ( a frame or a packet or a message ) with an error and asks the transmitter to retransmit that unit. Problems: 1. Correctness: Does the receiveraccept every transmission unit once and only once, and place them in the same order as the source. 2. Efficiency: Howmanyextra transmissions are made and howmuch time is spent in an idle state Channel model In a layered architecture, the channel model is the service provided by the lower layers of the architecture to the layer with the protocol The services provided by the protocol are provided to the layers above the protocol —variable delay —packets are receivedinthe same order that theyare transmitted. • This is not the case on the Internet • Alower layer of the architecture may re-order the packets when theyare receivedout of order, or may simply discard a packet if its sequence number is less than that of a previously received packet. • Exactly howthe sequencing is obtained, depends on the specific protocol that is used at the lower layer. • However, the guarantees are obtained does not concern the protocol at this layer. —Onahalf-duplexchannel, a lower layer coordinates transmissions between the source and receiverso that only one transmits at a time. —2types of losses 1. Unit 2nev erarrivesatthe receiver 2. Unit 4arrives, but an error is detected. 1 2 3 Xmitter t Lost Rcvd. Error Rcvr 4 -2- 2. Stop and wait ARQ —Full duplexchannel - the source and receivercan transmit messages to each other at the same time.
    [Show full text]
  • Sliding Window Protocol
    By B.A.Khivsara Asst Prof. Computer Dept SNJB’s KBJ COE,Chandwad Sliding window protocols are used where Reliable In- order delivery of packets is required, & such as in the Data Link Layer (OSI model) in the Transmission Control Protocol(TCP). The sliding window technique places varying limits on the number of data packets that are sent before waiting for an acknowledgment signal back from the receiving computer. The number of data packets is called the window size. protocols are divided into 2 types noiseless (error-free) channels noisy (error- creating) channels Figure Taxonomy of protocols 11.4 Let us first assume we have an ideal channel in which no frames are lost, duplicated, or corrupted. We introduce two protocols for this type of channel. The first is a protocol that does not use flow control; the second is the one use flow control. If data frames arrive at the receiver site faster than they can be processed, the frames must be stored until their use. To prevent the receiver from becoming overwhelmed with frames, we need to tell the sender to slow down. In this protocol the sender sends one frame, stops until it receives confirmation from the receiver and then sends the next frame. Figure Flow diagram for stop and wait Protocol 11.7 NOISY CHANNELS (Sliding Window Protocol) Although the Stop-and-Wait Protocol gives us an idea of how to add flow control to its predecessor, noiseless channels are nonexistent. We discuss three protocols in this section that use error control. Topics discussed in this section: Stop-and-Wait Automatic Repeat Request Go-Back-N Automatic Repeat Request Selective Repeat Automatic Repeat Request 11.8 Note Error correction in Stop-and-Wait ARQ is done by keeping a copy of the sent frame and retransmitting of the frame when the timer expires.
    [Show full text]
  • Go Back N Arq Protocol
    6.263/16.37: Lectures 3 & 4 The Data Link Layer: ARQ Protocols Eytan Modiano MIT Eytan Modiano 1 Automatic Repeat ReQuest (ARQ) • When the receiver detects errors in a packet, how does it let the transmitter know to re-send the corresponding packet? • Systems which automatically request the retransmission of missing packets or packets with errors are called ARQ systems. • Three common schemes – Stop & Wait – Go Back N – Selective Repeat Eytan Modiano 2 Pure Stop and Wait Protocol Transmitter departure times at A Time -----> packet 0 CRC packet 1 CRC packet 1 CRC ACK NAK arrival times at receiver Packet 0 Packet 1 Accepted Accepted • Problem: Lost Packets – Sender will wait forever for an acknowledgement • Packet may be lost due to framing errors • Solution: Use time-out (TO) – Sender retransmits the packet after a timeout Eytan Modiano 3 The Use Of Timeouts For Lost Packets Requires Sequence Numbers packet 0 CRC <---- timeout -----> packet 0 CRC packet 0 or 1? packet 0 accepted • Problem: Unless packets are numbered the receiver cannot tell which packet it received • Solution: Use packet numbers (sequence numbers) Eytan Modiano 4 Request Numbers Are Required On ACKs To Distinguish Packet ACKed 0 packet 0 timeout 0 packet 0 1 packet 1 ? ACK ACK Packet 0 accepted • REQUEST NUMBERS: – Instead of sending "ack" or "nak", the receiver sends the number of the packet currently awaited. – Sequence numbers and request numbers can be sent modulo 2. This works correctly assuming that 1) Frames travel in order (FCFS) on links 2) The CRC never fails to detect errors 3) The system is correctly initialized.
    [Show full text]
  • Implementing Immediate Forwarding for 4G in a Network Simulator
    Implementing immediate forwarding for 4G in a network simulator Magnus Vevik Austrheim Thesis submitted for the degree of Master in Programming and Networks 60 credits Department of Informatics Faculty of mathematics and natural sciences UNIVERSITY OF OSLO Autumn 2018 Implementing immediate forwarding for 4G in a network simulator Magnus Vevik Austrheim © 2018 Magnus Vevik Austrheim Implementing immediate forwarding for 4G in a network simulator http://www.duo.uio.no/ Printed: Reprosentralen, University of Oslo Contents 1 Introduction 3 1.1 Hypothesis . 4 1.2 Experimental Approach . 5 1.3 Limitations . 5 1.4 Research Method . 6 1.5 Main Contributions . 6 1.6 Outline . 7 2 Background 9 2.1 IP . 9 2.2 TCP . 9 2.2.1 Congestion Control and Avoidance . 10 2.2.2 Selective Acknowledgement (SACK) . 11 2.2.3 Recent Acknowlegment (RACK) . 12 2.3 Long Term Evolution (LTE) . 14 2.3.1 The need for LTE . 15 2.3.2 LTE Architecture . 17 2.3.3 LTE Air Interface . 19 2.4 LTE Radio Protocol Stack . 22 2.4.1 Packet Data Convergence (PDCP) . 22 2.4.2 Radio Link Control (RLC) . 23 2.4.3 Medium Access Control (MAC) . 26 2.4.4 Physical layer (PHY) . 29 2.5 Noise and Interference . 30 2.5.1 Signal transmission and reception . 30 2.5.2 Modulation schemes . 32 2.5.3 Propagation . 32 2.5.4 Fading . 33 2.5.5 Metrics . 33 3 Design 35 3.1 Hypothesis . 35 3.1.1 Throughput . 35 3.1.2 Latency . 36 3.1.3 Applicability .
    [Show full text]
  • E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall Description; Stage 2 (3GPP TS 36.300 Version 11.6.0 Release 11
    ETSI TS 136 300 V11.6.0 (2013-07) Technical Specification LTE; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (3GPP TS 36.300 version 11.6.0 Release 11) 3GPP TS 36.300 version 11.6.0 Release 11 1 ETSI TS 136 300 V11.6.0 (2013-07) Reference RTS/TSGR-0236300vb60 Keywords LTE ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice Individual copies of the present document can be downloaded from: http://www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http://portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http://portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced except as authorized by written permission.
    [Show full text]
  • A Comprehensive Overview of TCP Congestion Control in 5G Networks: Research Challenges and Future Perspectives
    sensors Review A Comprehensive Overview of TCP Congestion Control in 5G Networks: Research Challenges and Future Perspectives Josip Lorincz 1,* , Zvonimir Klarin 2 and Julije Ožegovi´c 1 1 Faculty of Electrical Engineering, Mechanical Engineering and Naval Architecture (FESB), University of Split, 21 000 Split, Croatia; [email protected] 2 Polytechnic of Sibenik, Trg Andrije Hebranga 11, 22 000 Sibenik, Croatia; [email protected] * Correspondence: [email protected] Abstract: In today’s data networks, the main protocol used to ensure reliable communications is the transmission control protocol (TCP). The TCP performance is largely determined by the used congestion control (CC) algorithm. TCP CC algorithms have evolved over the past three decades and a large number of CC algorithm variations have been developed to accommodate various network environments. The fifth-generation (5G) mobile network presents a new challenge for the implemen- tation of the TCP CC mechanism, since networks will operate in environments with huge user device density and vast traffic flows. In contrast to the pre-5G networks that operate in the sub-6 GHz bands, the implementation of TCP CC algorithms in 5G mmWave communications will be further compro- mised with high variations in channel quality and susceptibility to blockages due to high penetration losses and atmospheric absorptions. These challenges will be particularly present in environments such as sensor networks and Internet of Things (IoT) applications. To alleviate these challenges, this paper provides an overview of the most popular single-flow and multy-flow TCP CC algorithms used in pre-5G networks. The related work on the previous examinations of TCP CC algorithm Citation: Lorincz, J.; Klarin, Z.; performance in 5G networks is further presented.
    [Show full text]
  • Etsi Ts 136 300 V14.9.1 (2019-05)
    ETSI TS 136 300 V14.9.1 (2019-05) TECHNICAL SPECIFICATION LTE; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (3GPP TS 36.300 version 14.9.1 Release 14) 3GPP TS 36.300 version 14.9.1 Release 14 1 ETSI TS 136 300 V14.9.1 (2019-05) Reference RTS/TSGR-0236300ve91 Keywords LTE ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice The present document can be downloaded from: http://www.etsi.org/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI deliverable is the one made publicly available in PDF format at www.etsi.org/deliver. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following services: https://portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI.
    [Show full text]