US20090316665A1 - Downlink transmission synchronization and data buffer sizing in a radio access network - Google Patents
Downlink transmission synchronization and data buffer sizing in a radio access network Download PDFInfo
- Publication number
- US20090316665A1 US20090316665A1 US12/549,926 US54992609A US2009316665A1 US 20090316665 A1 US20090316665 A1 US 20090316665A1 US 54992609 A US54992609 A US 54992609A US 2009316665 A1 US2009316665 A1 US 2009316665A1
- Authority
- US
- United States
- Prior art keywords
- cfn
- offset
- toa
- update
- frame
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W56/00—Synchronisation arrangements
- H04W56/001—Synchronization between nodes
- H04W56/0015—Synchronization between nodes one node acting as a reference for the others
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B1/00—Details of transmission systems, not covered by a single one of groups H04B3/00 - H04B13/00; Details of transmission systems not characterised by the medium used for transmission
- H04B1/69—Spread spectrum techniques
- H04B1/707—Spread spectrum techniques using direct sequence modulation
- H04B1/7073—Synchronisation aspects
- H04B1/7075—Synchronisation aspects with code phase acquisition
- H04B1/70754—Setting of search window, i.e. range of code offsets to be searched
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B7/00—Radio transmission systems, i.e. using radiation field
- H04B7/14—Relay systems
- H04B7/15—Active relay systems
- H04B7/204—Multiple access
- H04B7/216—Code division or spread-spectrum multiple access [CDMA, SSMA]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B7/00—Radio transmission systems, i.e. using radiation field
- H04B7/24—Radio transmission systems, i.e. using radiation field for communication between two or more posts
- H04B7/26—Radio transmission systems, i.e. using radiation field for communication between two or more posts at least one of which is mobile
- H04B7/2643—Radio transmission systems, i.e. using radiation field for communication between two or more posts at least one of which is mobile using time-division multiple access [TDMA]
- H04B7/2656—Radio transmission systems, i.e. using radiation field for communication between two or more posts at least one of which is mobile using time-division multiple access [TDMA] for structure of frame, burst
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0278—Traffic management, e.g. flow control or congestion control using buffer status reports
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B7/00—Radio transmission systems, i.e. using radiation field
- H04B7/24—Radio transmission systems, i.e. using radiation field for communication between two or more posts
- H04B7/26—Radio transmission systems, i.e. using radiation field for communication between two or more posts at least one of which is mobile
- H04B7/2662—Arrangements for Wireless System Synchronisation
- H04B7/2671—Arrangements for Wireless Time-Division Multiple Access [TDMA] System Synchronisation
- H04B7/2678—Time synchronisation
- H04B7/2687—Inter base stations synchronisation
- H04B7/269—Master/slave synchronisation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04J—MULTIPLEX COMMUNICATION
- H04J3/00—Time-division multiplex systems
- H04J3/02—Details
- H04J3/06—Synchronising arrangements
- H04J3/0635—Clock or time synchronisation in a network
- H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
Definitions
- the present invention generally relates to downlink data transmission synchronization strategies in wireless communications and, more particularly, to algorithms for downlink data transmission synchronization and data buffer sizing in a radio access network.
- Radio link transmission is a synchronous communication.
- the serving radio network controller S-RNC
- BCH broadcast channel
- CFN connection frame number
- SFN system frame number
- the SFN is broadcast by L1 in the BCH.
- Data frames must be available at L1 on time for transmission at a specific CFN. This requires accurate and coordinated timing of each network node and transmission link on the data path there between. It is desirable to provide a system and method for handling downlink data transmission and for optimally sizing data buffers that are related to the transmission synchronization.
- a method for downlink data transmission synchronization and related buffer sizing in radio access networks is disclosed.
- the present application deals with the parameters of tight time of arrival (TOA), tight buffer size, downlink data transmission timing fine tuning through timing adjustment, and an advanced approach for radio access network frame number (RFN)/connection frame number (CFN) offset adjustment using quality of service (QoS) input.
- TOA tight time of arrival
- RNN radio access network frame number
- CFN connection frame number
- QoS quality of service
- Simple and efficient implementation strategies are disclosed for downlink data transmission synchronization handling that aim to avoid data dropping and related degradation in QoS.
- Target CFN initialization at transport bearer setup and subsequent time adjustment handling are addressed.
- Effective TOA window parameter setting, buffer design criteria, and TOA computation implementation with wrap-around constraints are provided.
- an advanced approach for RFN/CFN offset adjustment using QoS input, TOA sampling, transport bearer multiplexing, and processing capacity multiplexing information is presented. Fine-tuning of the RFN/CFN offset using a time alignment procedure is covered.
- a method for transmitting a data frame in a wireless communication system begins by creating a time of arrival (TOA) window, including a window start (WS) and a window end (WE).
- TOA time of arrival
- the TOA of the data frame at the air interface for transmission is determined, and further action is taken depending upon when the data frame arrives relative to the TOA window.
- the data frame is: (1) buffered if the TOA is before the WS, (2) transmitted if the TOA is within the TOA window, or (3) discarded if the TOA is after the WE.
- a method of adjusting the timing of a data frame for transmission in a wireless communication system begins by receiving a timing adjustment control frame containing a time of arrival (TOA) value for the data frame. An offset value based on the TOA value is calculated. A target connection frame number (CFN) for the data frame is obtained and the offset value is applied to the target CFN, to obtain an adjusted CFN. The data frame is transmitted at a time corresponding to the time of the adjusted CFN.
- TOA time of arrival
- FIG. 1 is a downlink transmission time line from a radio network controller (RNC) to a wireless transmit/receive unit (WTRU);
- RNC radio network controller
- WTRU wireless transmit/receive unit
- FIG. 2 is a diagram showing the time of arrival (TOA) window and related parameters
- FIG. 3 is a flowchart of a method for computing the TOA
- FIG. 4 is a flowchart of another method for computing the TOA
- FIGS. 5 a and 5 b are flowcharts of a method for calculating an initial CFN value
- FIG. 6 is a flowchart of a method for computing the RFN/CFN offset adjustment.
- FIG. 7 is a flowchart of a method for adjusting the target CFN value in the RNC for media access control (MAC).
- MAC media access control
- a wireless transmit/receive unit includes, but is not limited, to a user equipment, a mobile station, a fixed or mobile subscriber unit, a pager, or any other type of device capable of operating in a wireless environment.
- a base station includes, but is not limited to, a Node B, a site controller, an access point, or any other type of interfacing device in a wireless environment. It is noted that the numerical ranges and values provided in the description are exemplary, and that the concepts of the present invention are equally applicable to other numerical ranges and values.
- FIG. 1 is a timing diagram showing downlink (DL) transmissions from a RNC to a WTRU.
- the main delay components include:
- RNC internal processing delay which from the timing adjustment perspective includes frame protocol (FP) and other RNC sublayers on the data path under FP within the RNC.
- This processing delay definition assumes that the MAC protocol data unit (PDU) is prepared and ready to be transferred to the FP entity. Therefore, at the transmission time interval (TTI) boundary of the considered transport channel (or the coordinated transport channels if there are only dedicated channels (DCHs)), it is assumed that the MAC process has been initiated and has already performed the transport format combination indicator (TFCI) selection for the coded composite on which the transport channel is multiplexed. Moreover, the MAC has requested the data from the radio link control (RLC) buffer and this data has been already made available to the MAC.
- RLC radio link control
- Iur/Iub delay which represents the travel time of the frame over the Iur/Iub interface.
- TprocB which includes the waiting time of the frame in the FP process queue, cyclic redundancy check (CRC) computation (header and optionally payload for DCHs), and routing processing.
- CRC cyclic redundancy check
- TprocB can be aggregated with the Iur/Iub delay.
- Node B-cell interface delay which represents the travel time of the frame between the cell and the Node B.
- TprocC which represents the overall processing time on the cell, including the data transfer between cell processes down to the L1 processor.
- Timing adjustment is used to adapt the RNC transmission time such that each data frame is available at L1 on time for transmission on the air interface. Due to the various sources of delay, the frame needs to arrive at each processing stage within a certain time, in order to be at L1 in time for transmission.
- a frame that arrives too late will be discarded by the cell or the Node B, thus degrading the QoS.
- a frame that arrives too early will be buffered. In the latter situation, a frame could also be discarded if there is no space in the buffer, i.e., in a buffer overflow situation.
- the jitter values (especially on the Iur/Iub interface), and consequently the DL transmission delay, can be considered as random variables with a certain probability distribution.
- the jitter on the Iur/Iub interface depends to some degree on the data link technology used; for example, asynchronous transfer mode (ATM) technology will most likely exhibit more jitter than an Ethernet technology.
- ATM asynchronous transfer mode
- the time of arrival is a random variable that measures the jitter.
- a control window can be designed around the desired arrival time of the frame with a certain level of confidence. This window, called a TOA window, is characterized by two end-points, TOA window start (TOAWS) and TOA window end (TOAWE). TOAWS and TOAWE are determined by the RNC and are signaled to the Node B during the setup or reconfiguration of the transport bearers.
- timing adjustment control procedure is specified in the 3GPP specifications, there are no guidelines for the TOA window parameter design. Nor is there a directive on the calculation of TOA (with CFN wrap-around consideration) or on the determination of the adjustment to apply to the data transmission time at the RNC (MAC) when a timing adjustment control frame is received from the Node B.
- the Node B-cell interface is not standardized, and there is an assumption that both the Node B and the cell reside physically on the same hardware.
- a vendor could choose an architecture where a cell and the Node B reside at different locations and therefore on different pieces of hardware.
- the location of the FP entity can have an impact on the DL transmission timing control. Two possible locations for the FP entity are examined: on the Node B and on the cell.
- the TOA computation will not directly take into account the Node B-cell interface delay, especially at the channel setup.
- one idea is to set the cell processing time with an extra margin to account for the Node B-cell interface delay.
- the drawback of this design choice is the difficulty to quickly react to jitters on the Node B-cell interface and the resulting larger buffer build-up on the cell side with unacceptable service delay. This difficulty can be overcome by performing a procedure similar to the timing adjustment over the Node B-cell interface.
- the Node B sends a timing adjustment control frame to the RNC; or (b) the Node B autonomously changes the estimation of the cell processing time value to be used in future computations of TOA.
- alternative (b) While alternative (b) will also lead to the generation of a timing adjustment control frame by the Node B, from an implementation and performance point of view, alternative (a), which relies on a just-in-time strategy, is cleaner and has fewer variables to maintain. Also with alternative (a), there is no need to add an extra margin to the cell processing parameter (TprocC) and consequently, the buffer size on the cell side can be relatively small with little service delay. If both the SFN and BFN (Node B frame number) are not locked to each other, there is a possibility of long-term clock drift, which adds to the difficulty of timing adjustment handling when the FP is implemented on the Node B. However, if the cell is mapped to hardware with limited processing capability, then it might be desirable to offload the cell by implementing the FP handling on the Node B.
- TprocC cell processing parameter
- both the delays over the Iur/Iub interface and the Node B-cell interface are combined and are directly taken into account in the TOA computation.
- the processing time estimation strictly corresponds to the processing time on the cell, which results in a better approach from a timing adjustment perspective.
- the SFN is directly available and there is no need to have an extra conversion step from BFN to SFN.
- the FP entity resides on the Node B integrated on the same platform with the cells under control of the Node B, where both the Node B and the cells communicate over a high-speed bus at the hardware level, as opposed to a configuration where both nodes communicate with each other via a socket-like interface.
- a design goal for the window size is to have the FP frames arrive at the Node B at the following times:
- TOA and TOAWE have different origin points.
- the origin point for TOAWE is LTOA and is counted from right to left; i.e., TOAWE is always a positive value.
- the origin point for TOA is TOAWE, and is counted positively from TOAWE to the left and negatively from TOAWE to the right.
- a frame that is not too late for transmission (TOA ⁇ TOAWE; the cross-hatched area between TOAWE and LTOA as shown in FIG. 2 ) will be considered for buffering and will be transmitted at the target CFN included in the frame header by the RNC.
- the buffer size is greater than or equal to (TOAWS+TOAWE)/TTI, and is expressed in the same units as TOAWS and TOAWE.
- a frame arriving too late (TOA ⁇ TOAWE; to the right of LTOA as shown in FIG. 2 ) will be discarded.
- TOAWE is used to provide an extra margin on LTOA, such that late-arriving frames can still be processed. Therefore, TOAWE can be set to any valid arbitrary value. However, from an effective timing adjustment handling perspective, TOAWE should be set to a small number (one or two times TTI). If TOAWE is a large value, then the buffer size must also be large. This could cause a large buffer delay of a data frame, which could lead to frame collision (two different data frames with the same target CFN) and eventually frame drop, in the scenario where the target CFN is adjusted backward to handle the situation where frames are being received too early. Frames sent previously with the same target CFNs could still be waiting in the Node B-cell side buffer for transmission over the air interface, resulting in a collision.
- the TOAWS value is a measure of the variance of DL transmission delay between the RNC and the Node B for a given confidence level.
- the DL transmission delay between the RNC and the Node B can be modeled using a probability distribution, such as a normal distribution.
- a sample of the DL delay values can be gathered by using a node synchronization procedure.
- the node synchronization procedure is executed on both a high priority channel and a regular traffic channel.
- the execution of the node synchronization procedure on the high priority channel is used to estimate the time difference between the Node B clock and the RNC clock, in terms of the current frame number at both locations.
- the difference between the clocks is easy to determine, since it is assumed that there is no delay on the high priority channel.
- This estimated time difference is then used as a correction factor to the DL delay statistics gathered on a regular traffic channel (which has a delay), in order to offset the time difference component of the measurement. While the node synchronization procedure is described in 3GPP, its usage in support of timing adjustment and DL delay estimation is left to vendor implementation.
- the CFN range is from 0 to 255; i.e., the CFN cycle spans 256 radio frames, with each frame being 10 ms wide.
- T_CFN is the CFN cycle length, which is 2560 ms.
- the design objective is similar to TOAWE, in that the TOAWS value should be set such that the buffer delay is small.
- TOAWS could be set to no more than 100 ms.
- the preferred end-to-end delay is about 150 ms.
- the buffer on Node B-cell side should be large enough to hold all of the data frames with ⁇ TOAWE ⁇ TOA ⁇ TOAWS.
- the negative TOAWE value will encompass any frames in the window as well as late arriving frames (i.e., any frames between TOAWS and LTOA as shown in FIG. 2 ). This leads to a buffer size of:
- the buffer size can be defined as:
- This boundary can be a tied bound in the case of RT services, especially if TOAWE is suitably selected, and can provide a design advantage by avoiding the need to use a probability model.
- the TOA is computed as part of FP processing on the Node B.
- ScheduleCFN is the CFN value included in the frame received from the RNC and CurrentCFN is the CFN number (with respect to the SFN counter) that corresponds to the arrival time of the frame received from the RNC.
- ScheduleSFN is the SFN at which the data should be transmitted on the air by L1.
- SFN time is the time that corresponds to a given SFN on the time axis expressed in 1 ⁇ 8 ms units.
- CFN time is the time that corresponds to a given CFN on the time axis expressed in 1 ⁇ 8 ms units.
- TOA is transferred over the Iub interface with 1 ⁇ 8 ms resolution.
- TOA can then be represented as an integer ( 16 bits for non-PCH channels and 20 bits for PCH channels). Its computation is based on the following assumptions:
- TOAWS and TOAWE usage are based on their definitions in the NBAP specification (TS 25.433, 3GPP Technical Specification Group Radio Access Network: URTAN Iub Interface NBAP Signaling, section 9.2.1.61 for TOAWS and section 9.2.1.60 for TOAWE).
- TOAWS is a positive relative value with respect to the endpoint of the receiving window, while TOAWE is a positive relative value with respect the LTOA point on the time axis.
- TOAWS and TOAWE are stored in a database in 1 ⁇ 8 ms units.
- Tproc is an estimate of the processing time on the cell together with the Node B-cell interface delay stored in 1 ⁇ 8 ms units.
- the TOA is defined as:
- TOA is expressed as:
- TOA can also be expressed as:
- TOA (ScheduleCFN ⁇ CurrentCFN) ⁇ 80 ⁇ (CurrentSFN time ⁇ (CurrcntSFN time /80) ⁇ 80) ⁇ (TOAWE+ T proc) Equation (6)
- Equations (3)-(6) do not take into account the wrap-around effect of the CFN value that is kept between ⁇ 0, 255 ⁇ . Also these equations do not take into account the fact that the TOA range is ⁇ 1280 ms, 1279.875 ms ⁇ . These constraints are taken into account by additional steps discussed below.
- DCH dedicated channel
- DSCH DL shared channel
- FACH forward access channel
- the CFN is within a ⁇ 0, 255 ⁇ range and the TOA is within a ⁇ 1280, 1279.875 ms ⁇ range, i.e., ⁇ 10240, 10239 ⁇ in 1 ⁇ 8 ms units range.
- the CFN is within a ⁇ 0, 4095 ⁇ range and the TOA is within a ⁇ 20480 ms, +20479.875 ms ⁇ , i.e., ⁇ 163840, +163839 ⁇ in 1 ⁇ 8 ms units range.
- a method 300 for calculating the TOA for the DCH, the DSCH, or the FACH is shown in FIG. 3 .
- the method 300 begins by getting the CurrentBFNtime (step 302 ). Then, the CurrentSFNtime is calculated (step 304 ) according to:
- the value of CurrentCFN is computed according to Equations (8) or (9) (step 306 ).
- the TOA is calculated according to Equation (6) (step 308 ).
- Tproc 0 ms
- TOAWE 0 ms
- Frame Offset 0
- ScheduleCFN 0
- CurrentSFNtime 2550 ms, i.e., 20400 units (in 1 ⁇ 8 ms).
- a method 400 for calculating the TOA for the PCH is shown in FIG. 4 .
- the method 400 begins by getting the CurrentBFNtime (step 402 ). Then, the CurrentSFNtime is calculated (step 404 ) according to:
- the value of CurrentCFN is computed according to Equations (8) or (9) (step 406 ).
- the TOA is calculated according to Equation (6) (step 408 ).
- the CFN initialization includes computing the target CFN of the first transport block set (TBS) to be transmitted.
- TBS transport block set
- a CFN is associated with every TBS sent to L1 by L2 (the MAC).
- the transport channel synchronization procedure is used to initialize the CFN, i.e., the transmission time of the first TBS for a given connection. Once a CFN is assigned to a frame, the frame is sent on that CFN, so it is important to assign a CFN such that the frame can be properly processed prior to transmission. For example, if the target CFN is 80 , sending the frame at frame number 78 could lead to buffering and sending the frame at frame number 82 could cause the frame to be dropped.
- the transport channel synchronization procedure can also be used to perform TOA sampling in support of timing adjustment.
- a method 500 for target CFN initialization is shown in FIGS. 5 a and 5 b .
- the method 500 begins by setting a count timer (T_N, step 502 ) that ticks every 10 ms, i.e., the length of one radio frame.
- An initial value for N, which is used to find a target CFN value, is set (step 504 ) according to the equation:
- TOA_min an initial value for TOA_min is set (step 506 ).
- TOA is in a range of ⁇ 1280 ms, . . . , +1279.875 ms ⁇ .
- TOA_min is set to such a low value so that the sampling to be performed will permit the collection of the largest TOA value, which will be greater than TOA_min. There is no need to align the CFN boundary with RFN boundary; the objective is to align CFN boundary to the SFN boundary.
- a DL synchronization control frame is transmitted, with the target CFN equal to N obtained at step 504 (step 508 ).
- the DL synchronization control frame is sent a predetermined number (n) times, each time with a different target CFN value.
- the default value of n is 2 .
- a counter (i) is initialized and is used to count the number of samples collected, and a TOA statistic collection flag (TOA_Stat_Collection) is set to “on” to indicate that TOA statistics should be collected (step 510 ).
- TOA_Stat_Collection is set to “on” to indicate that TOA statistics should be collected
- step 514 a determination is made whether the system is collecting TOA statistics (whether the TOA_Stat_Collection flag is set to “on”; step 516 ). If the system is not presently collecting TOA statistics, then the method returns to the ready state (step 512 ). If the TOA statistics are being collected (step 516 ), then the value of N is incremented by one at every 10 ms tick of the timer (step 518 ). Next, a DL synchronization control frame with a target CFN equal to the incremented value of N is sent (step 520 ) and the method returns to the ready state (step 512 ).
- step 522 If the action is that an uplink (UL) synchronization control frame is received (step 522 ), this indicates that the Node B has received the previously sent DL synchronization control frame and sends the UL control frame to the RNC, which contains the Node B frame number corresponding to the received frame. Because the method 500 is being used to calculate the target CFN, the DL frame number and the UL frame number should be different. The TOA of the DL control frame is also calculated in step 522 . The sample counter is then incremented by one (step 524 ).
- the first portion of the method 500 (up to step 534 ) is used to collect statistics for calculating the target CFN, while the second portion of the method 500 (from step 536 on) determines the actual target CFN value to be used.
- the method 500 next computes a RFN_CFN_Offset value (step 536 ) according to one of two alternatives.
- the end of the TOA window is targeted, where data frames arrive at the Node B-cell just in time for transmission over the air interface, so there is no unnecessary initial data buffering.
- buffer delay is reduced and the risk of a frame being received too early before its scheduled transmission time at the Node B-cell is minimized. From a time adjustment perspective, it is desirable to minimize the buffer delay to avoid a frame arriving at the Node B too early. Timing adjustment performs better with a frame being late than a frame being early.
- the offset is defined as:
- the second alternative is to target the middle of TOA window, which is a more conservative approach.
- Data frames arrive at the middle of the window, reducing the probability of having frames arrive too early or late.
- the buffer delay is increased, since data will be buffered before transmission.
- RFN_CFN_Offset ⁇ (TOA_min ⁇ TOAWS/2)/80 ⁇ Equation (15)
- TOAWS/2 ⁇ TOA_min ⁇ TOAWS this indicates that the frame arrived in the second half of the window.
- the offset is used to target the first half of the window, towards the end of the window.
- the initial CFN value is set (step 538 ).
- CurrentSchedule_Based_Target_CFN Initial_CFN (step 540 ). From now on, CurrentSchedule_Based_Target_CFN is incremented by one at every tick of the CFN count timer (step 542 ). CurrentSchedule_Based_Target_CFN is the scheduled target CFN, including any offset; once this variable is set, it is used as a counter, since it represents the current target CFN.
- the variable Update_To_RFN_CFN_Offset_Adjustment is set to zero (step 546 ), and is used to track an adjustment to RFN_CFN_Offset, as described below.
- the method then terminates (step 530 ).
- An accurate CFN initialization avoids unnecessary initial data build-up in the RLC buffers. Therefore, the CFN initialization procedure should start as soon as the transport bearer establishment is completed. It desirable to complete this procedure before the first DL data to be transmitted becomes available in the RLC buffer.
- the CFN initialization can be accelerated by performing periodic sampling of the TOA as a background process.
- the transport bearers are configured to support different QoS levels. Sampling of the TOA should be performed for the transport bearers in each QoS category. Once a transport bearer is set up, an accurate CFN initialization can be achieved using the existing TOA information gathered through TOA sampling.
- the parameter n i.e., the number of TOA samplings required to execute CFN initialization (after establishment of the transport bearer) can then be small for obtaining a fairly accurate initial CFN.
- TOA_min used in the CFN initialization algorithm could be a weighted average of TOA_min computed after transport bearer establishment (steps 502 - 510 ) and TOA_min obtained through background sampling.
- the initial RFN_CFN_Offset adjustment computation is performed in a process other than MAC (in the RRC for instance), when the MAC applies this initial adjustment to obtain the initial CFN, the value of the initial CFN could have an offset error of one frame unless the MAC process has access to the tick count provided by timer set in step 502 and the corresponding CFN counter (the current value of N from steps 504 or 518 ).
- a method 600 for computing the RFN_CFN_Offset adjustment is shown in FIG. 6 . Before the method 600 is performed, is it assumed that the initialization procedure described above has been completed, and data transmission has begun. Due to the variable nature of the delay in the system, the exact value of the RFN_CFN_Offset is not known. The estimates calculated by the present invention are constantly adjusted to reflect this condition.
- the adjustment computation can either be implemented by the RRC process and passed on to the MAC process, or can be performed directly in the MAC process. In a preferred implementation, the adjustment computation is preformed by the RRC process and is an integer number of frames.
- the method 600 begins by determining whether the data frame arrives inside the TOA window (step 602 ). If the data frame arrives in the TOA window, then no adjustments are necessary, and the method terminates (step 604 ).
- a timing adjustment control frame is sent to the RNC with the TOA value (step 606 ).
- the timing adjustment control frame includes a TOA value, which indicates to the RNC how inaccurate the TOA of the frame was when it arrived at the Node B.
- This mechanism allows the FP on the Node B and consequently L1 to indicate back to the RNC (FP and MAC) the necessity to adjust the timing of the DL transmission.
- the timing adjustment i.e., changing the RFN_CFN_Offset
- RFN_CFN_Offset different adjustments are applied to RFN_CFN_Offset depending on whether a frame is received late (TOA ⁇ 0), too late (TOA ⁇ TOAWE), or too early (TOA>TOAWS) at the Node B-cell (step 608 ).
- the RNC applies the adjustment to the target CFN rather than to the transmission time at the RNC. Therefore, the adjustment computation formulas provided below produce the RFN_CFN_Offset adjustment as an integer number of frames, thus using the dividing factor 80.
- the target CFN value included in the FP data frame header is also expressed as an integer number of frames.
- the adjustment is applied to the RNC transmission time, it is still desirable to have the adjustment expressed as an integer number of frames; otherwise, the timer guarding the CFN count tick must be re-initialized to different starting points on the time axis which may require synchronization with the core network.
- RFN_CFN_Offset is computed as:
- New_RFN_CFN_Relative_Adjustment ⁇ (TOA ⁇ TOAWS/2)/80 ⁇ Equation (17)
- a frame arriving too late is an indication of a significant sudden increase in the traffic load, assuming that the design of the TOA window parameters is fairly accurate.
- the timing adjustment algorithm must then react quickly to correct the situation and avoid potential degradation in service quality.
- the frame can still be processed and transmitted over the air interface.
- the frame By moving the target CFN forward (with respect to RFN) by ⁇ TOA/80 frames (since TOA is negative in this case, the adjustment is a positive value), the frame should arrive at the window end point, assuming the traffic conditions remain the same. By targeting the end of the window, it is less likely that the frames will have to be buffered or dropped, since the frames will still be processed.
- the endpoint of the window is the ideal target CFN for these reasons.
- the rationale here is that the previous implicit RFN_CFN offset being used was leading to a situation of frames arriving late by TOA number of time units. An increase of this offset can be viewed as transmitting the frame earlier at the RNC side.
- the RFN_CFN_Offset value can be characterized by two main variables: the transmission time at the RNC (the MAC is considered as the reference transmission point) and the target CFN (transmission time by L1) on the cell. Practically, the adjustment to RFN_CFN_Offset can be applied by either moving the transmission time at the RNC or moving the target CFN.
- the target CFNs for future frames to be transmitted are moved forward or backward depending on whether the frames are received late or early.
- the drawback of this alternative is that for the scenario where the CFN is adjusted backward in order to delay data transmission, there could be an overlap of target CFNs included in a future frame with the target CFNs of frames previously sent, leading to frame collision on the cell side and resulting in frame drop.
- This side effect can be limited by having a tight buffer on the cell side and a good target CFN initialization with the design objective of having the data arrive just on time for transmission over the air interface.
- the present invention preferably applies the second strategy, to adjust the target CFN.
- the MAC After computing the required update (by either the RRC or the MAC) to RFN_CFN_Offset, the MAC adjusts the target CFN for future frames to be transmitted as indicated by the method 700 shown in FIG. 7 .
- the timer that controls the CFN counter increment is initialized and is run thereafter, providing timing ticks every 10 ms. Since the adjustment is made to the target CFN, there is no need to re-initialize the timer to a different starting point on the time axis.
- the method 700 begins by the MAC receiving a timer signal to increment the CFN counter (step 702 ) and the CurrentSchedule_Based_Target_CFN variable is incremented by one (step 704 ).
- a determination is made whether Update_To_RFN_CFN_Offset_Adjustment is equal to one, which indicates whether a new RFN_CFN_Offset_Adjustment value has been received since the last update to RFN_CFN_Offset (step 706 ). If Update_To_RFN_CFN_Offset_Adjustment is one, then New_Schedule_Based_Target_CFN is calculated (step 708 ) as follows:
- New_Schedule_Based_Target_CFN (CurrentSchedule_Based_Target_CFN+New_RFN_CFN_Offset_Relative_Adjustment/80)mod 256 Equation (19)
- the adjustment could be applied to the transmission time instead of to the target CFN.
- the RNC could buffer the data and concentrate processing power and other system resources on RT services, provided that the NRT services' QoS are met.
- the RFN_CFN_Offset adjustment can either be applied to the RNC transmission time or to the target CFN.
- the timing of data transmission time at the RNC can be fine tuned by instructing the core network to advance the delay of the data transmission.
- the timing adjustment can be used in combination with methods described above.
- the timing alignment could exclusively be used by the RNC to instruct the core network to advance the data transmission or delay the data transmission accordingly. Delaying the data transmission in the core network implies no unnecessary buffering in UTRAN (at the RNC side or the Node B-cell side).
- adjustments to the target CFN could be made on a frame scale basis, followed by fine-tuning the adjustment using the time alignment procedure.
- the time alignment procedure described in the 3GPP specifications or any similar procedure can be used to instruct the core network (GSM AMR vocoder, SMS center, etc.) to delay or advance its downlink data transmission timing.
- GSM AMR vocoder GSM AMR vocoder, SMS center, etc.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Synchronisation In Digital Transmission Systems (AREA)
- Communication Control (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Time-Division Multiplex Systems (AREA)
Abstract
Method and apparatus are disclosed for calculating a target connection frame number (CFN) for a data frame in wireless communications. An update to an offset between the CFN and a radio access network frame number is computed. A target CFN variable is incremented in response to a received timer signal. The value of an update variable is checked to determine whether a new value of the offset has been received since a previous update to the offset. A new target CFN is calculated using a current target CFN and the new value of the offset on a condition that the new value of the offset has been received. The current target CFN is set equal to the new target CFN.
Description
- This application claims priority from U.S. patent application Ser. No. 10/877,310 filed on Jun. 25, 2004, which claims priority from U.S. Provisional Application No. 60/482,300, filed Jun. 25, 2003, which is incorporated by reference as if fully set forth herein.
- The present invention generally relates to downlink data transmission synchronization strategies in wireless communications and, more particularly, to algorithms for downlink data transmission synchronization and data buffer sizing in a radio access network.
- Radio link transmission is a synchronous communication. Through the use of frame offsets, the serving radio network controller (S-RNC) establishes a time line for transmitted data relative to the broadcast channel (BCH), which serves as a time reference. The connection frame number (CFN) is not transmitted over the air interface. Instead, it is mapped by L1 (the air interface) to the system frame number (SFN), by using the L1 frame counter and a frame offset. The SFN is broadcast by L1 in the BCH. Data frames must be available at L1 on time for transmission at a specific CFN. This requires accurate and coordinated timing of each network node and transmission link on the data path there between. It is desirable to provide a system and method for handling downlink data transmission and for optimally sizing data buffers that are related to the transmission synchronization.
- A method for downlink data transmission synchronization and related buffer sizing in radio access networks (RAN) is disclosed. The present application deals with the parameters of tight time of arrival (TOA), tight buffer size, downlink data transmission timing fine tuning through timing adjustment, and an advanced approach for radio access network frame number (RFN)/connection frame number (CFN) offset adjustment using quality of service (QoS) input.
- Simple and efficient implementation strategies are disclosed for downlink data transmission synchronization handling that aim to avoid data dropping and related degradation in QoS. Target CFN initialization at transport bearer setup and subsequent time adjustment handling are addressed. Effective TOA window parameter setting, buffer design criteria, and TOA computation implementation with wrap-around constraints are provided. Moreover, an advanced approach for RFN/CFN offset adjustment using QoS input, TOA sampling, transport bearer multiplexing, and processing capacity multiplexing information is presented. Fine-tuning of the RFN/CFN offset using a time alignment procedure is covered.
- A method for transmitting a data frame in a wireless communication system begins by creating a time of arrival (TOA) window, including a window start (WS) and a window end (WE). The TOA of the data frame at the air interface for transmission is determined, and further action is taken depending upon when the data frame arrives relative to the TOA window. The data frame is: (1) buffered if the TOA is before the WS, (2) transmitted if the TOA is within the TOA window, or (3) discarded if the TOA is after the WE.
- A method of adjusting the timing of a data frame for transmission in a wireless communication system begins by receiving a timing adjustment control frame containing a time of arrival (TOA) value for the data frame. An offset value based on the TOA value is calculated. A target connection frame number (CFN) for the data frame is obtained and the offset value is applied to the target CFN, to obtain an adjusted CFN. The data frame is transmitted at a time corresponding to the time of the adjusted CFN.
- A more detailed understanding of the invention may be had from the following description of a preferred embodiment, given by way of example, and to be understood in conjunction with the accompanying drawings wherein:
-
FIG. 1 is a downlink transmission time line from a radio network controller (RNC) to a wireless transmit/receive unit (WTRU); -
FIG. 2 is a diagram showing the time of arrival (TOA) window and related parameters; -
FIG. 3 is a flowchart of a method for computing the TOA; -
FIG. 4 is a flowchart of another method for computing the TOA; -
FIGS. 5 a and 5 b are flowcharts of a method for calculating an initial CFN value; -
FIG. 6 is a flowchart of a method for computing the RFN/CFN offset adjustment; and -
FIG. 7 is a flowchart of a method for adjusting the target CFN value in the RNC for media access control (MAC). - Hereafter, a wireless transmit/receive unit (WTRU) includes, but is not limited, to a user equipment, a mobile station, a fixed or mobile subscriber unit, a pager, or any other type of device capable of operating in a wireless environment. When referred to hereafter, a base station includes, but is not limited to, a Node B, a site controller, an access point, or any other type of interfacing device in a wireless environment. It is noted that the numerical ranges and values provided in the description are exemplary, and that the concepts of the present invention are equally applicable to other numerical ranges and values.
-
FIG. 1 is a timing diagram showing downlink (DL) transmissions from a RNC to a WTRU. The main delay components include: - 1. RNC internal processing delay, which from the timing adjustment perspective includes frame protocol (FP) and other RNC sublayers on the data path under FP within the RNC. This processing delay definition assumes that the MAC protocol data unit (PDU) is prepared and ready to be transferred to the FP entity. Therefore, at the transmission time interval (TTI) boundary of the considered transport channel (or the coordinated transport channels if there are only dedicated channels (DCHs)), it is assumed that the MAC process has been initiated and has already performed the transport format combination indicator (TFCI) selection for the coded composite on which the transport channel is multiplexed. Moreover, the MAC has requested the data from the radio link control (RLC) buffer and this data has been already made available to the MAC.
- 2. Iur/Iub delay, which represents the travel time of the frame over the Iur/Iub interface.
- 3. Node B processing delay, TprocB, which includes the waiting time of the frame in the FP process queue, cyclic redundancy check (CRC) computation (header and optionally payload for DCHs), and routing processing. TprocB can be aggregated with the Iur/Iub delay.
- 4. Node B-cell interface delay, which represents the travel time of the frame between the cell and the Node B.
- 5. Cell processing delay, TprocC, which represents the overall processing time on the cell, including the data transfer between cell processes down to the L1 processor.
- The need for timing adjustment comes from the fact that there is variation (jitter) in the overall DL delay. Timing adjustment is used to adapt the RNC transmission time such that each data frame is available at L1 on time for transmission on the air interface. Due to the various sources of delay, the frame needs to arrive at each processing stage within a certain time, in order to be at L1 in time for transmission.
- A frame that arrives too late will be discarded by the cell or the Node B, thus degrading the QoS. A frame that arrives too early will be buffered. In the latter situation, a frame could also be discarded if there is no space in the buffer, i.e., in a buffer overflow situation. The jitter values (especially on the Iur/Iub interface), and consequently the DL transmission delay, can be considered as random variables with a certain probability distribution. The jitter on the Iur/Iub interface depends to some degree on the data link technology used; for example, asynchronous transfer mode (ATM) technology will most likely exhibit more jitter than an Ethernet technology.
- The time of arrival (TOA) is a random variable that measures the jitter. A control window can be designed around the desired arrival time of the frame with a certain level of confidence. This window, called a TOA window, is characterized by two end-points, TOA window start (TOAWS) and TOA window end (TOAWE). TOAWS and TOAWE are determined by the RNC and are signaled to the Node B during the setup or reconfiguration of the transport bearers.
- These definitions are shown diagrammatically in
FIG. 2 . As an example, assume that a confidence level of 99% is selected as a design parameter. With a careful design of the window, 99% of the transmitted data frames will fall into the expected window, leaving 1% of the transmitted data frames with a possibility of being discarded. This percentage of dropped frames can be further reduced with the remedy effect of the late time of arrival (LTOA) margin on TOAWE and the buffering of early frames. A correction to handle the trends is then applied by invoking the timing adjustment. - While the timing adjustment control procedure is specified in the 3GPP specifications, there are no guidelines for the TOA window parameter design. Nor is there a directive on the calculation of TOA (with CFN wrap-around consideration) or on the determination of the adjustment to apply to the data transmission time at the RNC (MAC) when a timing adjustment control frame is received from the Node B.
- Algorithms
- I. Location of Node B Frame Protocol and Timing Adjustment Handling
- In 3GPP, the Node B-cell interface is not standardized, and there is an assumption that both the Node B and the cell reside physically on the same hardware. However, a vendor could choose an architecture where a cell and the Node B reside at different locations and therefore on different pieces of hardware. In such cases, at the Node B-cell side of the Iub interface, the location of the FP entity can have an impact on the DL transmission timing control. Two possible locations for the FP entity are examined: on the Node B and on the cell.
- If the FP entity is implemented on the Node B, the TOA computation will not directly take into account the Node B-cell interface delay, especially at the channel setup. Under this scenario, one idea is to set the cell processing time with an extra margin to account for the Node B-cell interface delay. The drawback of this design choice is the difficulty to quickly react to jitters on the Node B-cell interface and the resulting larger buffer build-up on the cell side with unacceptable service delay. This difficulty can be overcome by performing a procedure similar to the timing adjustment over the Node B-cell interface. At the reception of a timing adjustment control frame from the cell, two alternatives are available: (a) the Node B sends a timing adjustment control frame to the RNC; or (b) the Node B autonomously changes the estimation of the cell processing time value to be used in future computations of TOA.
- While alternative (b) will also lead to the generation of a timing adjustment control frame by the Node B, from an implementation and performance point of view, alternative (a), which relies on a just-in-time strategy, is cleaner and has fewer variables to maintain. Also with alternative (a), there is no need to add an extra margin to the cell processing parameter (TprocC) and consequently, the buffer size on the cell side can be relatively small with little service delay. If both the SFN and BFN (Node B frame number) are not locked to each other, there is a possibility of long-term clock drift, which adds to the difficulty of timing adjustment handling when the FP is implemented on the Node B. However, if the cell is mapped to hardware with limited processing capability, then it might be desirable to offload the cell by implementing the FP handling on the Node B.
- If the FP entity is implemented on the cell, both the delays over the Iur/Iub interface and the Node B-cell interface are combined and are directly taken into account in the TOA computation. The processing time estimation strictly corresponds to the processing time on the cell, which results in a better approach from a timing adjustment perspective. Also, the SFN is directly available and there is no need to have an extra conversion step from BFN to SFN.
- As described herein, the FP entity resides on the Node B integrated on the same platform with the cells under control of the Node B, where both the Node B and the cells communicate over a high-speed bus at the hardware level, as opposed to a configuration where both nodes communicate with each other via a socket-like interface.
- II. Time of Arrival Window and Buffer Size Design Considerations
- A design goal for the window size is to have the FP frames arrive at the Node B at the following times:
- 1. No later than the reference time (TOA=0) when the estimated Iur/Iub delay is at a maximum.
- 2. No earlier than TOA=TOAWS when the Iur/Iub delay is at a minimum.
- The relationship of TOA, TOAWS, and TOAWE can be seen with reference to
FIG. 2 . TOA and TOAWE have different origin points. The origin point for TOAWE is LTOA and is counted from right to left; i.e., TOAWE is always a positive value. The origin point for TOA is TOAWE, and is counted positively from TOAWE to the left and negatively from TOAWE to the right. - A frame that is not too late for transmission (TOA≧−TOAWE; the cross-hatched area between TOAWE and LTOA as shown in
FIG. 2 ) will be considered for buffering and will be transmitted at the target CFN included in the frame header by the RNC. The buffer size is greater than or equal to (TOAWS+TOAWE)/TTI, and is expressed in the same units as TOAWS and TOAWE. - A frame arriving too late (TOA≦−TOAWE; to the right of LTOA as shown in
FIG. 2 ) will be discarded. - TOAWE is used to provide an extra margin on LTOA, such that late-arriving frames can still be processed. Therefore, TOAWE can be set to any valid arbitrary value. However, from an effective timing adjustment handling perspective, TOAWE should be set to a small number (one or two times TTI). If TOAWE is a large value, then the buffer size must also be large. This could cause a large buffer delay of a data frame, which could lead to frame collision (two different data frames with the same target CFN) and eventually frame drop, in the scenario where the target CFN is adjusted backward to handle the situation where frames are being received too early. Frames sent previously with the same target CFNs could still be waiting in the Node B-cell side buffer for transmission over the air interface, resulting in a collision.
- The TOAWS value is a measure of the variance of DL transmission delay between the RNC and the Node B for a given confidence level. The DL transmission delay between the RNC and the Node B can be modeled using a probability distribution, such as a normal distribution. A sample of the DL delay values can be gathered by using a node synchronization procedure. For this purpose, the node synchronization procedure is executed on both a high priority channel and a regular traffic channel. The execution of the node synchronization procedure on the high priority channel is used to estimate the time difference between the Node B clock and the RNC clock, in terms of the current frame number at both locations. The difference between the clocks is easy to determine, since it is assumed that there is no delay on the high priority channel. This estimated time difference is then used as a correction factor to the DL delay statistics gathered on a regular traffic channel (which has a delay), in order to offset the time difference component of the measurement. While the node synchronization procedure is described in 3GPP, its usage in support of timing adjustment and DL delay estimation is left to vendor implementation.
- TOAWS can be set as k×σ, where k is an integer according to the desired confidence level and a is the standard deviation of the DL transmission distribution. Since the TOA value range is {−1280 ms, +1279.875 ms}, it is reasonable to impose the constraint that TOAWS≦T_CFN/2=1.28 sec. (or 20.48 sec. for the physical channel (PCH)). The CFN range is from 0 to 255; i.e., the CFN cycle spans 256 radio frames, with each frame being 10 ms wide. T_CFN is the CFN cycle length, which is 2560 ms.
- Given the service end-to-end delay and the fact that TOAWS is strongly correlated with the DL transmission delay, it is also reasonable to impose the constraint that TOAWS<α×ADJ, where ADJ denotes acceptable delay jitter on the DL over the Iub/Iur interface given the overall delay acceptable for the type of service being considered, and a is a coefficient between {0,1}. The delay jitter is the variation present in the delay, not the delay itself. The delay between the RNC and the Node B is not constant, due to varying traffic levels in the system. This variable delay is the reason for using the TOA window; if the delay was constant, the window would not be needed because the TOA of the frame would always be known.
- Both ADJ and α can be configurable parameters, and the parameters of the probability distribution (normal distribution) must be selected such that TOAWS=(k×σ)<(α×ADJ). The design objective is similar to TOAWE, in that the TOAWS value should be set such that the buffer delay is small. Especially for real time (RT) services, TOAWS could be set to no more than 100 ms. For conversational voice and video services, the preferred end-to-end delay is about 150 ms.
- The buffer on Node B-cell side should be large enough to hold all of the data frames with −TOAWE<TOA≦TOAWS. The negative TOAWE value will encompass any frames in the window as well as late arriving frames (i.e., any frames between TOAWS and LTOA as shown in
FIG. 2 ). This leads to a buffer size of: -
┌TOAWS+TOAWE)/TTI┐ Equation (1) - In case of a variable TTI, the smallest TTI is used. Data that arrives early at the Node B (TOA>TOAWS) can still be buffered, but the buffer size is designed to hold only the data frames with −TOAWE<TOA≦TOAWS. With respect to the preferred design constraints imposed on TOAWS, the buffer size can be defined as:
-
┌((α×ADJ)+TOAWE)/TTI┐ Equation (2) - This boundary can be a tied bound in the case of RT services, especially if TOAWE is suitably selected, and can provide a design advantage by avoiding the need to use a probability model.
- III. TOA Computation
- The TOA is computed as part of FP processing on the Node B. ScheduleCFN is the CFN value included in the frame received from the RNC and CurrentCFN is the CFN number (with respect to the SFN counter) that corresponds to the arrival time of the frame received from the RNC.
- The following parameters are defined:
- 1. ScheduleSFN is the SFN at which the data should be transmitted on the air by L1.
- 2. CurrentSFN is the current SFN.
- 3. SFNtime is the time that corresponds to a given SFN on the time axis expressed in ⅛ ms units.
- 4. CFNtime is the time that corresponds to a given CFN on the time axis expressed in ⅛ ms units.
- The TOA value is transferred over the Iub interface with ⅛ ms resolution. TOA can then be represented as an integer (16 bits for non-PCH channels and 20 bits for PCH channels). Its computation is based on the following assumptions:
- 1. TOAWS and TOAWE usage are based on their definitions in the NBAP specification (TS 25.433, 3GPP Technical Specification Group Radio Access Network: URTAN Iub Interface NBAP Signaling, section 9.2.1.61 for TOAWS and section 9.2.1.60 for TOAWE). TOAWS is a positive relative value with respect to the endpoint of the receiving window, while TOAWE is a positive relative value with respect the LTOA point on the time axis.
- 2. At transport bearer setup or reconfiguration, TOAWS and TOAWE are stored in a database in ⅛ ms units.
- 3. Tproc is an estimate of the processing time on the cell together with the Node B-cell interface delay stored in ⅛ ms units.
- 4. CurrentBFNtime, the time that corresponds to the current Node B frame number, is received through an API call to a timer library and is expressed in ⅛ ms units.
- 5. CurrentSFNtime=CurrentBFNtime+SFN_BFN_Offset. SFN_BFN_Offset is the difference between the SFN and the BFN and is in the range {−40959.875 ms×8, . . . 0, . . . +40959.875 ms×8}={−327679, . . . 0, . . . +327679} in resolution of ⅛ ms units.
- 6. Radio Frame Period=10 ms×8=80 in ⅛ ms units.
- In general, the TOA is defined as:
-
TOA=(ScheduleTime−Tproc−TOAWE)−CurrentTime Equation (3) - In SFN reference, TOA is expressed as:
-
TOA=(ScheduleSFNtime−Tproc−TOAWE)−CurrentSFNtime Equation (4) - In CFN notation, TOA can also be expressed as:
-
TOA=(ScheduleCFNtime−Tproc−TOAWE)−CurrentCFNtime Equation (5) - that is:
-
TOA=(ScheduleCFN−CurrentCFN)×80−(CurrentSFNtime−└(CurrcntSFNtime/80)┘×80)−(TOAWE+Tproc) Equation (6) - Equations (3)-(6) do not take into account the wrap-around effect of the CFN value that is kept between {0, 255}. Also these equations do not take into account the fact that the TOA range is {−1280 ms, 1279.875 ms}. These constraints are taken into account by additional steps discussed below.
- In order to save on computation performance, the quantity
-
└(CurrentSFNtime/80)┘ Equation (7) - should be evaluated only once and then be re-used in both the CurrentCFN and TOA formulas.
- CurrentCFN is computed with the following formulas:
- For the dedicated channel (DCH) and the DL shared channel (DSCH),
-
CurrentCFN=(└(CurrentSFNtime/80)+256┘−Frame Offset)mod 256 Equation (8) - For the forward access channel (FACH),
-
CurrentCFN=└(CurrentSFNtime/80)┘mod 256 Equation (9) - For the PCH,
-
CurrentCFN=└(CurrentSFNtime/80)┘mod 4096 Equation (10) - IV. TOA Computation with CFN Wrap-Around Constraints
- For the DCH, the DSCH, or the FACH, the CFN is within a {0, 255} range and the TOA is within a {−1280, 1279.875 ms} range, i.e., {−10240, 10239} in ⅛ ms units range.
- For the PCH, the CFN is within a {0, 4095} range and the TOA is within a {−20480 ms, +20479.875 ms}, i.e., {−163840, +163839} in ⅛ ms units range.
- The wrap-around constraints on the CFN can be taken into account by simply ensuring that the TOA is within the range described above. A
method 300 for calculating the TOA for the DCH, the DSCH, or the FACH is shown inFIG. 3 . Themethod 300 begins by getting the CurrentBFNtime (step 302). Then, the CurrentSFNtime is calculated (step 304) according to: -
CurrentSFNtime=(CurrentBFNtime+SFN_BFN_Offset) Equation (11) - SFN_BFN_Offset is expressed in ⅛ ms units. Also at the L1, the relation SFN=(BFN+SFN_BFN_Offset) is used for the SFN_BFN_Offset calculation.
- The value of CurrentCFN is computed according to Equations (8) or (9) (step 306). Next, the TOA is calculated according to Equation (6) (step 308).
- The TOA value is then evaluated (step 310). If TOA≧10240, then TOA=TOA=TOA−20480 (step 312). The method then returns to step 310 to evaluate the adjusted TOA value. If TOA<−10240 (step 310), then TOA=TOA+20480 (step 314). The method then returns to step 310 to evaluate the adjusted TOA value. If −10240≦TOA≦10239 (step 310), then no change is made to the TOA value (step 316) and the method terminates (step 318).
Steps - As an example of the
method 300, assume that: Tproc=0 ms; TOAWE=0 ms; Frame Offset=0; ScheduleCFN=0; and CurrentSFNtime=2550 ms, i.e., 20400 units (in ⅛ ms). CurrentCFN=floor (20400/80)mod 256=255. Based on these values and preliminary calculations, -
TOA=(0−255×80−0−(0+0)=−20400 - Since TOA<−10240, then TOA=−20400+20480=+10 ms.
- A
method 400 for calculating the TOA for the PCH is shown inFIG. 4 . Themethod 400 begins by getting the CurrentBFNtime (step 402). Then, the CurrentSFNtime is calculated (step 404) according to: -
CurrentSFNtime=(CurrentBFNtime+SFN_BFN_Offset)×⅛ Equation (12) - The value of CurrentCFN is computed according to Equations (8) or (9) (step 406). Next, the TOA is calculated according to Equation (6) (step 408).
- The TOA value is then evaluated (step 410). If TOA≧163840, then TOA=TOA=TOA−327680 (step 412). The method then returns to step 410 to evaluate the adjusted TOA value. If TOA<−163840 (step 410), then TOA=TOA+327680 (step 414). The method then returns to step 410 to evaluate the adjusted TOA value. If −163840≦TOA≦163839 (step 410), then no change is made to the TOA value (step 416) and the method terminates (step 418).
Steps - V. Target CFN Initialization
- The CFN initialization includes computing the target CFN of the first transport block set (TBS) to be transmitted. A CFN is associated with every TBS sent to L1 by L2 (the MAC). The transport channel synchronization procedure is used to initialize the CFN, i.e., the transmission time of the first TBS for a given connection. Once a CFN is assigned to a frame, the frame is sent on that CFN, so it is important to assign a CFN such that the frame can be properly processed prior to transmission. For example, if the target CFN is 80, sending the frame at frame number 78 could lead to buffering and sending the frame at frame number 82 could cause the frame to be dropped. The transport channel synchronization procedure can also be used to perform TOA sampling in support of timing adjustment.
- A
method 500 for target CFN initialization is shown inFIGS. 5 a and 5 b. Themethod 500 begins by setting a count timer (T_N, step 502) that ticks every 10 ms, i.e., the length of one radio frame. An initial value for N, which is used to find a target CFN value, is set (step 504) according to the equation: -
N=└(Current RFNtime/80)┘mod 256 Equation (13) - Then an initial value for TOA_min is set (step 506). According to the 3GPP specification, TOA is in a range of {−1280 ms, . . . , +1279.875 ms}. An arbitrary strict lower bound can therefore be set on TOA as TOA_min=−2560×80, expressed in ⅛ ms units. TOA_min is set to such a low value so that the sampling to be performed will permit the collection of the largest TOA value, which will be greater than TOA_min. There is no need to align the CFN boundary with RFN boundary; the objective is to align CFN boundary to the SFN boundary.
- A DL synchronization control frame is transmitted, with the target CFN equal to N obtained at step 504 (step 508). To perform the sampling, which is done in order to obtain a better estimate for the target CFN, the DL synchronization control frame is sent a predetermined number (n) times, each time with a different target CFN value. In one exemplary implementation, the default value of n is 2. Next a counter (i) is initialized and is used to count the number of samples collected, and a TOA statistic collection flag (TOA_Stat_Collection) is set to “on” to indicate that TOA statistics should be collected (step 510). After the variables have been initialized, the method is in a ready state, waiting to respond to an action from the system (step 512).
- If the action is that a 10 ms timer tick is received from the timer T_N (step 514), a determination is made whether the system is collecting TOA statistics (whether the TOA_Stat_Collection flag is set to “on”; step 516). If the system is not presently collecting TOA statistics, then the method returns to the ready state (step 512). If the TOA statistics are being collected (step 516), then the value of N is incremented by one at every 10 ms tick of the timer (step 518). Next, a DL synchronization control frame with a target CFN equal to the incremented value of N is sent (step 520) and the method returns to the ready state (step 512).
- If the action is that an uplink (UL) synchronization control frame is received (step 522), this indicates that the Node B has received the previously sent DL synchronization control frame and sends the UL control frame to the RNC, which contains the Node B frame number corresponding to the received frame. Because the
method 500 is being used to calculate the target CFN, the DL frame number and the UL frame number should be different. The TOA of the DL control frame is also calculated instep 522. The sample counter is then incremented by one (step 524). - A determination is made whether the current TOA value is greater than TOA_min (step 526). If TOA is not greater than TOA_min, then no change is made to TOA_min (step 528), and the method returns to the ready state (step 512). If TOA is greater than TOA_min (step 526), then TOA_min is set to the current TOA value (step 530). A determination is then made whether all of the predetermined number of samples have been collected (i>n; step 532). If all of the samples have not been collected, then the method returns to the ready state (step 512). If all of the samples have been collected (step 532), then the TOA statistic collection is turned off(step 534).
- The first portion of the method 500 (up to step 534) is used to collect statistics for calculating the target CFN, while the second portion of the method 500 (from
step 536 on) determines the actual target CFN value to be used. Themethod 500 next computes a RFN_CFN_Offset value (step 536) according to one of two alternatives. - In the first alternative, the end of the TOA window is targeted, where data frames arrive at the Node B-cell just in time for transmission over the air interface, so there is no unnecessary initial data buffering. By targeting the end of the TOA window, buffer delay is reduced and the risk of a frame being received too early before its scheduled transmission time at the Node B-cell is minimized. From a time adjustment perspective, it is desirable to minimize the buffer delay to avoid a frame arriving at the Node B too early. Timing adjustment performs better with a frame being late than a frame being early. In this alternative, the offset is defined as:
-
RFN_CFN_Offset=−└TOA_min/80┘ Equation (14) - The second alternative is to target the middle of TOA window, which is a more conservative approach. Data frames arrive at the middle of the window, reducing the probability of having frames arrive too early or late. However, the buffer delay is increased, since data will be buffered before transmission. This approach also increases the end-to-end delay, which makes the first approach preferable. If TOA=TOAWS/2 (i.e., exactly in the middle of the window), then RFN_CFN_Offset=0, because no adjustment needs to be made, since the middle of the window has already been targeted. Otherwise, the offset is defined as:
-
RFN_CFN_Offset=−└(TOA_min−TOAWS/2)/80┘ Equation (15) - It is noted that while the equation used to calculate the offset is the same, the effect of the offset depends upon the value of TOA_min.
- If TOA_min≦0, this indicates that the frame is late, and the application of the offset will target the beginning of the window by providing additional delay to hit the desired frame number.
- If TOA_min>TOAWS, this indicates that the frame arrived too early and that the delay was overestimated. The offset is used to decrease the delay to target the end of the window.
- If 0<TOA_min<TOAWS/2, this indicates that the frame arrived in the first half of the window. The offset is used to target the second half of the window, towards the start of the window. Because positive values are counted from TOAWE towards TOAWS, the first half of the window has a lower TOA value, even though is would appear to the right of TOAWS as shown in
FIG. 2 . - If TOAWS/2<TOA_min<TOAWS, this indicates that the frame arrived in the second half of the window. The offset is used to target the first half of the window, towards the end of the window.
- After the RFN_CFN_Offset has been calculated, at the next tick from the count timer set at
step 502, the initial CFN value is set (step 538). -
Initial_CFN=N+RFN_CFN_Offset Equation (16) - Then set CurrentSchedule_Based_Target_CFN=Initial_CFN (step 540). From now on, CurrentSchedule_Based_Target_CFN is incremented by one at every tick of the CFN count timer (step 542). CurrentSchedule_Based_Target_CFN is the scheduled target CFN, including any offset; once this variable is set, it is used as a counter, since it represents the current target CFN.
- Data transmission is started if there is data in the RLC buffer (after system processing) and is assigned a CFN=CurrentSchedule_Based_Target_CFN (step 544). The variable Update_To_RFN_CFN_Offset_Adjustment is set to zero (step 546), and is used to track an adjustment to RFN_CFN_Offset, as described below. The method then terminates (step 530).
- An accurate CFN initialization avoids unnecessary initial data build-up in the RLC buffers. Therefore, the CFN initialization procedure should start as soon as the transport bearer establishment is completed. It desirable to complete this procedure before the first DL data to be transmitted becomes available in the RLC buffer. The CFN initialization can be accelerated by performing periodic sampling of the TOA as a background process. In typical commercial systems, the transport bearers are configured to support different QoS levels. Sampling of the TOA should be performed for the transport bearers in each QoS category. Once a transport bearer is set up, an accurate CFN initialization can be achieved using the existing TOA information gathered through TOA sampling. The parameter n, i.e., the number of TOA samplings required to execute CFN initialization (after establishment of the transport bearer) can then be small for obtaining a fairly accurate initial CFN. For instance, TOA_min used in the CFN initialization algorithm could be a weighted average of TOA_min computed after transport bearer establishment (steps 502-510) and TOA_min obtained through background sampling.
- If the initial RFN_CFN_Offset adjustment computation is performed in a process other than MAC (in the RRC for instance), when the MAC applies this initial adjustment to obtain the initial CFN, the value of the initial CFN could have an offset error of one frame unless the MAC process has access to the tick count provided by timer set in
step 502 and the corresponding CFN counter (the current value of N fromsteps 504 or 518). - VI. RFN_CFN_Offset Adjustment Determination After CFN Initialization
- A
method 600 for computing the RFN_CFN_Offset adjustment is shown inFIG. 6 . Before themethod 600 is performed, is it assumed that the initialization procedure described above has been completed, and data transmission has begun. Due to the variable nature of the delay in the system, the exact value of the RFN_CFN_Offset is not known. The estimates calculated by the present invention are constantly adjusted to reflect this condition. - The adjustment computation can either be implemented by the RRC process and passed on to the MAC process, or can be performed directly in the MAC process. In a preferred implementation, the adjustment computation is preformed by the RRC process and is an integer number of frames. The
method 600 begins by determining whether the data frame arrives inside the TOA window (step 602). If the data frame arrives in the TOA window, then no adjustments are necessary, and the method terminates (step 604). - When a data frame arrives outside of the TOA window at the Node B (step 602), a timing adjustment control frame is sent to the RNC with the TOA value (step 606). The timing adjustment control frame includes a TOA value, which indicates to the RNC how inaccurate the TOA of the frame was when it arrived at the Node B. This mechanism allows the FP on the Node B and consequently L1 to indicate back to the RNC (FP and MAC) the necessity to adjust the timing of the DL transmission. The timing adjustment (i.e., changing the RFN_CFN_Offset) is made to control and minimize the transmission delay and the buffering time for transmission on the air interface.
- In an exemplary embodiment, different adjustments are applied to RFN_CFN_Offset depending on whether a frame is received late (TOA<0), too late (TOA<−TOAWE), or too early (TOA>TOAWS) at the Node B-cell (step 608). In one embodiment, the RNC applies the adjustment to the target CFN rather than to the transmission time at the RNC. Therefore, the adjustment computation formulas provided below produce the RFN_CFN_Offset adjustment as an integer number of frames, thus using the dividing
factor 80. The target CFN value included in the FP data frame header is also expressed as an integer number of frames. Even in the cases where the adjustment is applied to the RNC transmission time, it is still desirable to have the adjustment expressed as an integer number of frames; otherwise, the timer guarding the CFN count tick must be re-initialized to different starting points on the time axis which may require synchronization with the core network. - If a frame is received too late at the Node B-cell, i.e., TOA<−TOAWE, this indicates that the offset was underestimated. The offset should therefore be increased and targets the middle of the window. This is a conservative approach, and helps reduce the risk of frames being dropped. The adjustment to RFN_CFN_Offset is computed as:
-
New_RFN_CFN_Relative_Adjustment=−└(TOA−TOAWS/2)/80┘ Equation (17) - A frame arriving too late is an indication of a significant sudden increase in the traffic load, assuming that the design of the TOA window parameters is fairly accurate. The timing adjustment algorithm must then react quickly to correct the situation and avoid potential degradation in service quality.
- If a frame is received late at the Node B-cell, i.e., −TOAWE≦TOA<0, the frame can still be processed and transmitted over the air interface.
-
New_RFN_CFN_Relative_Adjustment=−└TOA/80┘ Equation (18) - By moving the target CFN forward (with respect to RFN) by −TOA/80 frames (since TOA is negative in this case, the adjustment is a positive value), the frame should arrive at the window end point, assuming the traffic conditions remain the same. By targeting the end of the window, it is less likely that the frames will have to be buffered or dropped, since the frames will still be processed. The endpoint of the window is the ideal target CFN for these reasons. The rationale here is that the previous implicit RFN_CFN offset being used was leading to a situation of frames arriving late by TOA number of time units. An increase of this offset can be viewed as transmitting the frame earlier at the RNC side.
- If a frame is received too early at the Node B-cell, i.e., TOA>TOAWS, this is an indication that the initial offset was too large, and the New_RFN_CFN_Relative_Adjustment is calculated as in Equation (18). By moving the target CFN backward (with respect to the RFN) by TOA/80 frames (TOA is a positive value in this case), the frame should arrive at the window end point assuming the traffic conditions remain the same. After the New_RFN_CFN_Relative_Adjustment value is calculated (step 608), it is sent to the MAC (step 610), and the method terminates (step 604). Based on the adjustment made in the
method 600, the CurrentSchedule_Based_Target_CFN will also change, since it is based on the value of the offset. - VII. Strategies for Delaying or Accelerating Data Transmission Upon Reception of Timing Adjustment Control Frame
- Given the Iur/Iub delay and the processing delays on the data transmission path between the RNC and the Node B-cell, the RFN_CFN_Offset value can be characterized by two main variables: the transmission time at the RNC (the MAC is considered as the reference transmission point) and the target CFN (transmission time by L1) on the cell. Practically, the adjustment to RFN_CFN_Offset can be applied by either moving the transmission time at the RNC or moving the target CFN.
- If the strategy selected is to move the transmission time on the RNC, frames arriving early at the Node B-cell implies that future frames to be transmitted will also be delayed at the RNC. This means missing potentially valuable radio frames at the Node B for data transmission and will lead to unnecessary data build-up in the RNC buffers, the potential increase of end-to-end delay, and eventually the degradation of QoS as a result of frames being dropped. For real time (RT) services, delaying data transmission leads to data buffering, which will most likely conflict with associated QoS requirements due to the stringent end-to-end delay requirements. However, if the time alignment procedure with the core network is supported, the capability to delay the data transmission time can be used to fine tune the timing adjustment. Also, for non-real time (NRT) services, the data frame could be delayed in favor of RT services.
- If a frame arrives late or too late at the Node B-cell, then the data must be sent earlier. The difficulty here is that the transmission time cannot be moved backward since obviously, the elapsed time cannot be recovered. In this case, it is too late to transmit certain frames. These frames will either be dropped locally at the RNC or will be transmitted toward the Node B and will most likely be dropped at the Node B-cell side, leading to the possibility of generating cascading timing adjustment control frames.
- If the strategy is to move the target CFN, then the target CFNs for future frames to be transmitted are moved forward or backward depending on whether the frames are received late or early. The drawback of this alternative is that for the scenario where the CFN is adjusted backward in order to delay data transmission, there could be an overlap of target CFNs included in a future frame with the target CFNs of frames previously sent, leading to frame collision on the cell side and resulting in frame drop. This side effect can be limited by having a tight buffer on the cell side and a good target CFN initialization with the design objective of having the data arrive just on time for transmission over the air interface. The present invention preferably applies the second strategy, to adjust the target CFN.
- VIII. Basic Approach
- After computing the required update (by either the RRC or the MAC) to RFN_CFN_Offset, the MAC adjusts the target CFN for future frames to be transmitted as indicated by the
method 700 shown inFIG. 7 . At CFN initialization, the timer that controls the CFN counter increment is initialized and is run thereafter, providing timing ticks every 10 ms. Since the adjustment is made to the target CFN, there is no need to re-initialize the timer to a different starting point on the time axis. - The
method 700 begins by the MAC receiving a timer signal to increment the CFN counter (step 702) and the CurrentSchedule_Based_Target_CFN variable is incremented by one (step 704). A determination is made whether Update_To_RFN_CFN_Offset_Adjustment is equal to one, which indicates whether a new RFN_CFN_Offset_Adjustment value has been received since the last update to RFN_CFN_Offset (step 706). If Update_To_RFN_CFN_Offset_Adjustment is one, then New_Schedule_Based_Target_CFN is calculated (step 708) as follows: -
New_Schedule_Based_Target_CFN=(CurrentSchedule_Based_Target_CFN+New_RFN_CFN_Offset_Relative_Adjustment/80)mod 256 Equation (19) - CurrentSchedule_Based_Target_CFN is then set to New_Schedule_Based_Target_CFN (step 710). The variable Update_To_RFN_CFN_Offset_Adjustment is set to zero (step 712), to indicate that there has been no change to RFN_CFN_Offset since the last update. Then TFCI selection continues and data is transmitted is there is data in the RLC buffer (step 714), and the method terminates (step 716).
- IX. Advanced Approach
- In case of multiplexing of several users on the same transport bearer (for instance, a data frame belonging to several users sharing the same ATM virtual channel) or competing for the same processing device resources, the adjustment on one user might negatively impact other users. An advanced approach can be implemented as follows:
- 1. Apply the Basic Approach as described above.
- 2. Based on QoS characteristics (type of service and acceptable end-to-end delay) and TOA statistics, certain users' data could be delayed or advanced as a result of the adjustment made in the Basic Approach. This assumes that there is a background collection of TOA samples through periodic execution of the transport channel synchronization procedure.
- 3. Compute the adjustments as described in the
method 600 and apply these adjustments following themethod 700. In the case of NRT services, the adjustment could be applied to the transmission time instead of to the target CFN. For instance, in case of a frame arriving too early, the RNC could buffer the data and concentrate processing power and other system resources on RT services, provided that the NRT services' QoS are met. - X. Extension to Time Alignment Procedure Over RNC—Core Network Interface (Iu):
- As discussed above, the RFN_CFN_Offset adjustment can either be applied to the RNC transmission time or to the target CFN. The timing of data transmission time at the RNC can be fine tuned by instructing the core network to advance the delay of the data transmission. Especially for a small RFN_CFN_Offset value (less than one radio frame for instance), the timing adjustment can be used in combination with methods described above. In the case of a frame arriving at the Node B with small TOA values, the timing alignment could exclusively be used by the RNC to instruct the core network to advance the data transmission or delay the data transmission accordingly. Delaying the data transmission in the core network implies no unnecessary buffering in UTRAN (at the RNC side or the Node B-cell side). In case of a larger TOA, adjustments to the target CFN could be made on a frame scale basis, followed by fine-tuning the adjustment using the time alignment procedure.
- The time alignment procedure described in the 3GPP specifications or any similar procedure can be used to instruct the core network (GSM AMR vocoder, SMS center, etc.) to delay or advance its downlink data transmission timing.
- Although the features and elements of the present invention are described in the preferred embodiments in particular combinations, each feature or element can be used alone (without the other features and elements of the preferred embodiments) or in various combinations with or without other features and elements of the present invention.
- While specific embodiments of the present invention have been shown and described, many modifications and variations could be made by one skilled in the art without departing from the scope of the invention. The above description serves to illustrate and not limit the particular invention in any way.
Claims (6)
1. A method for calculating a target connection frame number (CFN) for a data frame in wireless communications, comprising:
computing an update to an offset between the CFN and a radio access network frame number (RFN);
incrementing a target CFN variable in response to a received timer signal;
determining whether a new value of the offset has been received since a previous update to the offset by checking the value of an update variable;
calculating a new target CFN using a current target CFN and the new value of the offset on a condition that the new value of the offset has been received;
setting the current target CFN equal to the new target CFN; and
changing the update variable to indicate that a new value of the offset has not been received on a condition that the new value of the offset has not been received.
2. The method of claim 1 , further comprising
computing the offset update for each of several multiplexed users; and
using each user's offset update to delay or advance that user's frame transmission relative to the frame transmission of the other users.
3. The method of claim 2 , wherein each offset update is computed based on at least one of: quality of service characteristics, or time-of-arrival (TOA) statistics.
4. A radio network controller (RNC) configured to calculate a target connection frame number (CFN) for a data frame in wireless communications, the RNC comprising a medium access control (MAC) circuitry configured to:
compute an update to an offset between the CFN and a radio access network frame number (RFN);
increment a target CFN variable in response to a received timer signal;
determine whether a new value of the offset has been received since a previous update to the offset by checking the value of an update variable;
calculate a new target CFN using a current target CFN and the new value of the offset on a condition that the new value of the offset has been received;
set the current target CFN equal to the new target CFN; and
change the update variable to indicate that a new value of the offset has not been received on a condition that the new value of the offset has not been received.
5. The RNC of claim 4 , wherein the MAC circuitry is configured to compute the offset update for each of several multiplexed users and to use each user's offset update to delay or advance that user's frame transmission relative to the frame transmission of the other users.
6. The RNC of claim 5 , wherein the MAC circuitry is configured to compute each offset update based on at least one of: quality of service characteristics, or time-of-arrival (TOA) statistics.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/549,926 US20090316665A1 (en) | 2003-06-25 | 2009-08-28 | Downlink transmission synchronization and data buffer sizing in a radio access network |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US48230003P | 2003-06-25 | 2003-06-25 | |
US10/877,310 US7583653B2 (en) | 2003-06-25 | 2004-06-25 | Method for downlink transmission synchronization and data buffer sizing in a radio access network |
US12/549,926 US20090316665A1 (en) | 2003-06-25 | 2009-08-28 | Downlink transmission synchronization and data buffer sizing in a radio access network |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/877,310 Continuation US7583653B2 (en) | 2003-06-25 | 2004-06-25 | Method for downlink transmission synchronization and data buffer sizing in a radio access network |
Publications (1)
Publication Number | Publication Date |
---|---|
US20090316665A1 true US20090316665A1 (en) | 2009-12-24 |
Family
ID=33563844
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/877,310 Expired - Fee Related US7583653B2 (en) | 2003-06-25 | 2004-06-25 | Method for downlink transmission synchronization and data buffer sizing in a radio access network |
US12/549,926 Abandoned US20090316665A1 (en) | 2003-06-25 | 2009-08-28 | Downlink transmission synchronization and data buffer sizing in a radio access network |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/877,310 Expired - Fee Related US7583653B2 (en) | 2003-06-25 | 2004-06-25 | Method for downlink transmission synchronization and data buffer sizing in a radio access network |
Country Status (11)
Country | Link |
---|---|
US (2) | US7583653B2 (en) |
EP (2) | EP2180618A3 (en) |
JP (1) | JP2007525080A (en) |
KR (3) | KR20090086607A (en) |
CN (2) | CN100502594C (en) |
AR (1) | AR044903A1 (en) |
CA (1) | CA2544581A1 (en) |
MX (1) | MXPA05014177A (en) |
NO (1) | NO20060367L (en) |
TW (3) | TW200539595A (en) |
WO (1) | WO2005004337A2 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090207814A1 (en) * | 2003-12-26 | 2009-08-20 | Ntt Docomo, Inc. | Radio communications system, radio network controller and base station |
US20100315998A1 (en) * | 2007-11-21 | 2010-12-16 | Fujitsu Limited | Communication Apparatus, Base Station Apparatus And Data Reception Timing Synchronizing Method |
US20110116443A1 (en) * | 2009-11-13 | 2011-05-19 | Jungji Yu | Apparatus for ethernet traffic aggregation of radio links |
US8094767B1 (en) * | 2005-12-12 | 2012-01-10 | Exalt Communications Inc. | Method and apparatus for timing and/or frequency synchronization in an RF receiver |
US20150103726A1 (en) * | 2013-10-16 | 2015-04-16 | Samsung Electronics Co., Ltd. | Method and apparatus for reducing delay in wireless communication system supporting broadcast service |
Families Citing this family (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100834639B1 (en) | 2002-12-30 | 2008-06-02 | 엘지노텔 주식회사 | Method of Time Synchronization of Downlink User Plane |
AU2003263702A1 (en) * | 2003-09-11 | 2005-03-29 | Telefonaktiebolaget Lm Ericsson (Publ) | Method for discarding all segments corresponding to the same packet in a buffer |
CN101049032B (en) * | 2004-05-05 | 2012-07-18 | 艾利森电话股份有限公司 | HSDPA flow control data frame delay RNC reference time |
US20080084822A1 (en) * | 2004-10-08 | 2008-04-10 | Telefonaktiebolaget Lm Ericsson (Publ) | Congestion Control Within A Radio Access Network |
US7898954B2 (en) * | 2004-10-20 | 2011-03-01 | Qualcomm Incorporated | Power-efficient data reception in a communication system with variable delay |
KR100678972B1 (en) * | 2006-01-05 | 2007-02-06 | 삼성전자주식회사 | Apparatus and method for transmitting/receiving wireless data |
SG138490A1 (en) * | 2006-06-23 | 2008-01-28 | Sony Corp | Methods and apparatus for estimating time of arrival of a pulse in a train of pulses in a ranging system |
US9304964B2 (en) * | 2006-06-30 | 2016-04-05 | Intel Corporation | Separable transport layer in cache coherent multiple component microelectronic systems |
WO2008087724A1 (en) * | 2007-01-18 | 2008-07-24 | Mitsubishi Electric Corporation | Wireless communication system |
US7792082B2 (en) * | 2007-06-28 | 2010-09-07 | Alcatel-Lucent Usa Inc. | Dynamic expansion of a frame selection interval in a wireless communication network |
CN101355789B (en) * | 2007-07-26 | 2011-11-02 | 华为技术有限公司 | Method for obtaining connection frame number and communication system as well as relevant equipment |
CN101389072B (en) * | 2007-09-12 | 2011-05-25 | 中兴通讯股份有限公司 | Transmission channel synchronization/time regulation method for high-speed downlink sharing channel |
JP4924322B2 (en) * | 2007-09-21 | 2012-04-25 | 富士通株式会社 | Frame synchronization method and base station controller |
CN101527674B (en) * | 2008-03-04 | 2011-04-27 | ***通信集团公司 | Method and device for processing data |
GB0805787D0 (en) * | 2008-03-31 | 2008-04-30 | Roke Manor Research | A multilateration method and apparatus |
JP2013515431A (en) * | 2009-12-21 | 2013-05-02 | トムソン ライセンシング | Simultaneous transmission feasible in wireless networks |
CN102014431B (en) * | 2010-11-08 | 2013-09-11 | 华为技术有限公司 | Anti-jittering data transmission method, equipment and system |
CN102754396B (en) * | 2011-06-23 | 2015-11-25 | 华为技术有限公司 | Send method and the gateway device of data |
WO2014070053A1 (en) | 2012-10-31 | 2014-05-08 | Telefonaktiebolaget L M Ericsson (Publ) | Dynamic transport channel synchronization |
US9674836B2 (en) * | 2014-01-27 | 2017-06-06 | Spectrum Effect, Inc. | Method and system for coexistence of radar and communication systems |
US9825748B2 (en) | 2014-02-03 | 2017-11-21 | Apple Inc. | Offloading and reselection policies and rules for mobile devices |
EP3162134B1 (en) | 2014-06-27 | 2020-12-30 | Telefonaktiebolaget LM Ericsson (publ) | Inter-rnc transport channel synchronization |
US10313143B1 (en) * | 2015-02-23 | 2019-06-04 | Sprint Communications Company L.P. | Wireless communication system to provide buffering in a single frequency network |
KR102350504B1 (en) * | 2015-04-27 | 2022-01-14 | 삼성전자주식회사 | Apparatus and method for controlling downlink throughput in communication system |
CN106658596A (en) * | 2015-10-29 | 2017-05-10 | 中兴通讯股份有限公司 | Data packet processing method, data packet processing device, and communication system |
Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5490204A (en) * | 1994-03-01 | 1996-02-06 | Safco Corporation | Automated quality assessment system for cellular networks |
US6243369B1 (en) * | 1998-05-06 | 2001-06-05 | Terayon Communication Systems, Inc. | Apparatus and method for synchronizing an SCDMA upstream or any other type upstream to an MCNS downstream or any other type downstream with a different clock rate than the upstream |
US20010046240A1 (en) * | 1998-11-05 | 2001-11-29 | Fabio Longoni | Frame synchronization mechanism |
US20020009129A1 (en) * | 2000-06-24 | 2002-01-24 | Samsung Electronics Co., Ltd. | Apparatus and method for synchronization of uplink synchronous transmission scheme in a CDMA communication system |
US20020105933A1 (en) * | 2000-06-12 | 2002-08-08 | Shinichi Higuchi | Internode synchronizing device and internode synchronizing method |
US20030016670A1 (en) * | 2001-07-23 | 2003-01-23 | Michael Seidl | Smart interface for payload transfers in networking applications |
US20030048810A1 (en) * | 2001-09-13 | 2003-03-13 | Alcatel | Digital signal processor multi-channel time alignment device and method, e.g. for voice channels at the Iu-cs interface in UTRAN telecommunications |
US20030117997A1 (en) * | 2001-12-20 | 2003-06-26 | Lg Electronics Inc. | Maintaining synchronization between a radio network controller and a base station |
US20030161325A1 (en) * | 2000-04-12 | 2003-08-28 | Sami Kekki | Transporting information in a communication system |
US20030219005A1 (en) * | 2002-04-30 | 2003-11-27 | Nortel Networks Limited | Method for controlling exchanges of frames between a control unit and at least one radio station, and control unit for implementing the method |
US20040008646A1 (en) * | 2002-04-27 | 2004-01-15 | Samsung Electronics Co., Ltd. | Soft handover method for multimedia broadcast/multicast service in a CDMA mobile communication system |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5872820A (en) * | 1996-09-30 | 1999-02-16 | Intel Corporation | Synchronization in TDMA systems in a non-realtime fashion |
TW506199B (en) | 2000-04-06 | 2002-10-11 | Interdigital Tech Corp | Synchronization of time advance and deviation |
JP2003102053A (en) * | 2001-09-20 | 2003-04-04 | Matsushita Electric Ind Co Ltd | Communication system and communication method |
-
2004
- 2004-06-24 TW TW093141264A patent/TW200539595A/en unknown
- 2004-06-24 KR KR1020097013090A patent/KR20090086607A/en not_active Application Discontinuation
- 2004-06-24 WO PCT/US2004/020426 patent/WO2005004337A2/en active Search and Examination
- 2004-06-24 EP EP10000873A patent/EP2180618A3/en not_active Withdrawn
- 2004-06-24 TW TW096122194A patent/TW200838203A/en unknown
- 2004-06-24 CN CNB2004800174328A patent/CN100502594C/en not_active Expired - Fee Related
- 2004-06-24 EP EP04756110A patent/EP1637001A4/en not_active Ceased
- 2004-06-24 CA CA002544581A patent/CA2544581A1/en not_active Abandoned
- 2004-06-24 MX MXPA05014177A patent/MXPA05014177A/en not_active Application Discontinuation
- 2004-06-24 JP JP2006517664A patent/JP2007525080A/en active Pending
- 2004-06-24 CN CNA2008101839579A patent/CN101459485A/en active Pending
- 2004-06-24 TW TW093118362A patent/TWI253264B/en not_active IP Right Cessation
- 2004-06-24 KR KR1020057024937A patent/KR100752105B1/en not_active IP Right Cessation
- 2004-06-24 KR KR1020067003981A patent/KR20060027415A/en not_active Application Discontinuation
- 2004-06-25 US US10/877,310 patent/US7583653B2/en not_active Expired - Fee Related
- 2004-06-25 AR ARP040102223A patent/AR044903A1/en unknown
-
2006
- 2006-01-24 NO NO20060367A patent/NO20060367L/en not_active Application Discontinuation
-
2009
- 2009-08-28 US US12/549,926 patent/US20090316665A1/en not_active Abandoned
Patent Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5490204A (en) * | 1994-03-01 | 1996-02-06 | Safco Corporation | Automated quality assessment system for cellular networks |
US6243369B1 (en) * | 1998-05-06 | 2001-06-05 | Terayon Communication Systems, Inc. | Apparatus and method for synchronizing an SCDMA upstream or any other type upstream to an MCNS downstream or any other type downstream with a different clock rate than the upstream |
US20010046240A1 (en) * | 1998-11-05 | 2001-11-29 | Fabio Longoni | Frame synchronization mechanism |
US20030161325A1 (en) * | 2000-04-12 | 2003-08-28 | Sami Kekki | Transporting information in a communication system |
US20020105933A1 (en) * | 2000-06-12 | 2002-08-08 | Shinichi Higuchi | Internode synchronizing device and internode synchronizing method |
US20020009129A1 (en) * | 2000-06-24 | 2002-01-24 | Samsung Electronics Co., Ltd. | Apparatus and method for synchronization of uplink synchronous transmission scheme in a CDMA communication system |
US20030016670A1 (en) * | 2001-07-23 | 2003-01-23 | Michael Seidl | Smart interface for payload transfers in networking applications |
US20030048810A1 (en) * | 2001-09-13 | 2003-03-13 | Alcatel | Digital signal processor multi-channel time alignment device and method, e.g. for voice channels at the Iu-cs interface in UTRAN telecommunications |
US20030117997A1 (en) * | 2001-12-20 | 2003-06-26 | Lg Electronics Inc. | Maintaining synchronization between a radio network controller and a base station |
US20040008646A1 (en) * | 2002-04-27 | 2004-01-15 | Samsung Electronics Co., Ltd. | Soft handover method for multimedia broadcast/multicast service in a CDMA mobile communication system |
US20030219005A1 (en) * | 2002-04-30 | 2003-11-27 | Nortel Networks Limited | Method for controlling exchanges of frames between a control unit and at least one radio station, and control unit for implementing the method |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090207814A1 (en) * | 2003-12-26 | 2009-08-20 | Ntt Docomo, Inc. | Radio communications system, radio network controller and base station |
US8045590B2 (en) * | 2003-12-26 | 2011-10-25 | Ntt Docomo, Inc. | Radio communications system, radio network controller and base station |
US8094767B1 (en) * | 2005-12-12 | 2012-01-10 | Exalt Communications Inc. | Method and apparatus for timing and/or frequency synchronization in an RF receiver |
US20100315998A1 (en) * | 2007-11-21 | 2010-12-16 | Fujitsu Limited | Communication Apparatus, Base Station Apparatus And Data Reception Timing Synchronizing Method |
US8611332B2 (en) * | 2007-11-21 | 2013-12-17 | Fujitsu Limited | Communication apparatus, base station apparatus and data reception timing synchronizing method |
US20110116443A1 (en) * | 2009-11-13 | 2011-05-19 | Jungji Yu | Apparatus for ethernet traffic aggregation of radio links |
US8611356B2 (en) | 2009-11-13 | 2013-12-17 | Exalt Communications Incorporated | Apparatus for ethernet traffic aggregation of radio links |
US20150103726A1 (en) * | 2013-10-16 | 2015-04-16 | Samsung Electronics Co., Ltd. | Method and apparatus for reducing delay in wireless communication system supporting broadcast service |
US9749814B2 (en) * | 2013-10-16 | 2017-08-29 | Samsung Electronics Co., Ltd | Method and apparatus for reducing delay in wireless communication system supporting broadcast service |
Also Published As
Publication number | Publication date |
---|---|
AR044903A1 (en) | 2005-10-05 |
KR20060026891A (en) | 2006-03-24 |
US7583653B2 (en) | 2009-09-01 |
US20050025194A1 (en) | 2005-02-03 |
JP2007525080A (en) | 2007-08-30 |
EP1637001A2 (en) | 2006-03-22 |
EP2180618A2 (en) | 2010-04-28 |
CN1810053A (en) | 2006-07-26 |
CA2544581A1 (en) | 2005-01-13 |
TW200501696A (en) | 2005-01-01 |
KR20060027415A (en) | 2006-03-27 |
NO20060367L (en) | 2006-03-23 |
TW200838203A (en) | 2008-09-16 |
CN100502594C (en) | 2009-06-17 |
KR20090086607A (en) | 2009-08-13 |
MXPA05014177A (en) | 2006-02-24 |
TWI253264B (en) | 2006-04-11 |
EP2180618A3 (en) | 2013-01-02 |
CN101459485A (en) | 2009-06-17 |
WO2005004337A2 (en) | 2005-01-13 |
KR100752105B1 (en) | 2007-08-28 |
EP1637001A4 (en) | 2006-12-13 |
TW200539595A (en) | 2005-12-01 |
WO2005004337A3 (en) | 2005-06-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7583653B2 (en) | Method for downlink transmission synchronization and data buffer sizing in a radio access network | |
US11800395B2 (en) | Method, system and device for providing flow control in a split bearer environment | |
US8503299B2 (en) | Method and system for packet scheduling | |
KR100580852B1 (en) | Block error rate estimate reporting for target signal to interference ratio adjustment | |
EP1903690A1 (en) | Synchronous delivery method | |
EP1667351A1 (en) | Transmission parameter control device | |
EP1912377A1 (en) | System and method for transmitting/receiving multicast/broadcast signal in a communication system | |
US6353742B1 (en) | Method and apparatus for backhauling data in a communication system | |
US8493928B2 (en) | Wireless system, for packet communication between base station and mobile stations | |
US20040246898A1 (en) | Method and system for flow control for route switching | |
US7626974B2 (en) | Frame synchronisation in a radio access network | |
EP1743497B1 (en) | Hsdpa flow control data frame delay rnc reference time | |
EP4362411A1 (en) | Methods of ue-assisted report | |
US20240007886A1 (en) | Burst monitoring method and apparatus | |
CN117939514A (en) | User equipment auxiliary reporting method and user equipment | |
JP2002217959A (en) | Method and device for controlling transmission timing | |
TW202418788A (en) | Methods of ue-assisted report and ue | |
Sagfors et al. | Transmission offset adaptation in UTRAN | |
Pedreno et al. | Improving the performance of DCH timing adjustment in 3G networks | |
Park et al. | On the efficacy of PPPMux within radio access network |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO PAY ISSUE FEE |