Abstract
SCTP (Stream control transmission protocol) is a new transport layer protocol that was published as RFC2960 by IETF (the Internet Engineering Task Force) in October 2000 and amended in RFC4960 in September 2007. SCTP provides reliable ordered and unordered transport services. The congestion control and flow control mechanisms for SCTP are very similar to those for TCP (transmission control protocol). SCTP can apply more than one IP address when establishing associations. SCTP multihoming can support multiple paths in association. These features provide SCTP with some network-level fault tolerance through network address redundancy. SCTP multihoming has tremendous transmission potential. However, SCTP path management is very simple in RFC4960 and therefore cannot effectively distinguish path conditions; it also has no path switch strategy appropriate for wireless networking. These factors all degrade SCTP performance. This study proposes a new path management (quality-aware SCTP) for wireless networks; this includes a new path failure detection method and ICE (idle path congestion window size estimation) mechanism. An experiment using NS2 was performed, showing that quality-aware SCTP can effectively improve the network performance. Quality-aware SCTP is simple and provides a more effective performance than SCTP alone.
1. Introduction
SCTP is a new transport layer protocol that was published as RFC2960/RFC4960 [1] by the IETF [2] in October 2000/September 2007. The design was inspired by the PSTN (public switched telephone network). SCTP was originally designed to provide transport services for SS7 signaling messages over IP networks.
SCTP, TCP, and UDP are transport layer protocols in IP (network layer) architecture. SCTP is a connection-oriented transport protocol similar to TCP. The congestion control and flow control mechanisms of SCTP are very similar to those of TCP, including slow start, congestion avoidance, and fast retransmission. Other significant features of SCTP include multihoming, multistream, SACK (selective acknowledgement), and reliable ordered/unordered transmission service.
SCTP Multihoming
SCTP supports the multihoming communication scheme. An SCTP association has a broader concept than a TCP connection. SCTP can apply more than one IP address to establish associations, while TCP simply connects two endpoints using addresses and port numbers. The SCTP multihoming feature supports a path transfer to alternative paths without disconnecting, thus providing some network-level fault tolerance.
An SCTP node needs to perform a setup procedure to establish a communication relationship by exchanging state information. This relationship, called an SCTP association, uses a four-way handshake and an extra cookie mechanism for security (to prevent SYN flooding attacks).
Many modern portable devices have multiple network interfaces to communicate with different devices. For instance, many portable computers can use more than one NIC (wireless network interface card) to connect with different wireless/heterogeneous networks.
A portable device transmits data using only one of the interfaces at a time even when it has multiple interfaces. Therefore, selecting a path from associations for transmitting data is a very important issue. SCTP multihoming increases the flexibility of paths and thus improves the transmission efficiency.
An association between two multihoming endpoints creates many paths between them. The path that transmits data is called the primary path; the others are secondary paths and are for alternative paths and fault tolerance. If an error occurs for the primary path and there is a data transmission failure, then the SCTP automatically changes the data transmission path to one of the secondary paths.
A secondary path is simply an alternative path in multihoming, and also named as idle path in the following because of no actual data transmission on it. However, the approach of checking whether the primary path condition is active or inactive influences the timing of the switch to the secondary path.
This study described how to identify the primary path condition and also analyzed the defects of SCTP in path management for wireless networks to propose a new solution termed quality-aware SCTP, which is simple and improves the efficiency of the path selection mechanism. A two-state Markov chain was applied as the loss model to simulate the channel error in a wireless network [3]. Experiments were performed using NS2 [4], to demonstrate that the proposed solution performs better than the original mechanism at minimizing the degradation of transmission.
The remainder of this study is organized as follows. Section 2 describes related work, and Section 3 introduces SCTP path management; Section 4 then describes the proposed quality-aware SCTP path management. Experimental and simulation results are presented in Section 5. Conclusions are drawn in Section 6.
2. Related Work
In transport mobility management, a CN (corresponding node) and an MN (mobile node) may communicate with each other via SCTP. An MN has more than one interface card to connect to different wireless networks. Since the MN has many available network interfaces, the link between the CN and MN has many independent transmission paths (multihoming). The CN can select one of the IP addresses in the MN as the transmission destination to allow different paths for data transmission. Once the CN connects with the MN, one pair of IP addresses is used to establish a link as the primary path for data transmission, while all other possible pairs of IP addresses constitute alternative paths. Thus, the SCTP path measurement mechanism is very important in a wireless network and strongly affects the transmission efficiency.
The condition of a wireless network changes rapidly. Therefore, users have bad surfing experiences if they do not reselect appropriate networks (i.e., communication paths) at the appropriate time. For example, although IEEE 802.11 has a layer-2 expiration, which increases the transmission success rate, it still has a much higher PLR (packet loss rate) in a wireless network than current ethernet standards for a wired network; this is due to unexpected handoffs and signal instability. Weak signal strength, handoff, and noise result in packet loss in a wireless network.
Multihoming can improve network transmission performance [5]. When the primary path fails, SCTP either retransmits data across a secondary path or replaces the primary path. Both approaches decrease the transmission performance.
SCTP has a congestion control mechanism like TCP, and it has a multihoming feature that TCP lacks. Therefore, two factors influence SCTP transmission efficiency: the size of the congestion window size of each transmission path and the active status of each path. Most studies focus on optimizing the congestion window size. Some have proposed various path management strategies [6, 7].
Packet loss in wired networks is mainly the result of network congestion. SCTP congestion control must adjust the congestion window size. Conversely, packet loss in a wireless network is mainly from channel noise or temporary disconnections (e.g., handoffs). If the SCTP congestion control adjusts the congestion window size in wireless network due to other factors instead of network congestion, then performance falls. Huang and Tsai [8] focused on handover issues while adopting multipath transmission in wireless mobile networks. This paper addressed and resolved three concerns related to path handover: spurious retransmissions, retransmissions of data lost, and reordering problem.
On the other hand, WiSE [6] applies bottleneck bandwidth estimation techniques to infer whether losses are a result of congestion or radio channel errors. If the packet loss is due to channel errors, WiSE does not adjust the congestion window size. W-A SCTP [9] determines the reason for packet loss from the packet’s label. When the network becomes congested, W-A SCTP labels followup packets with ECN (explicit congestion notification). The reason for packet loss is identified from whether packets have this label.
However, the advantages in the use of multiple wireless interfaces and multihoming will waste without an efficient management of available paths. AISLE [7] proposes an autonomic mechanism that enables nodes to select the optimum radio interface. The authors evaluated the bottleneck bandwidth to choose the primary path for transmitting data in general conditions that maximize the throughput of multiinterface stations. Nevertheless, AISLE’s selection does not reflect transmission error or packet loss. With packet loss in a wireless network, the throughput does not only depend on the bottleneck bandwidth. Thus, our study takes transmission error and packet loss into consideration.
In addition, other factors also affect SCTP transmission efficiency. In SACK [10], SCTP multihoming leads to stalling due to errors in some cases. Consequently, the error decisions by SACK disturb packet transmission. Stalling dampens transmission efficiency due to unnecessary waiting. Two main conditions lead to stalling: alternative paths that underestimate the RTO (retransmission timeout) value, and the SCTP sender not knowing that the path is active when a network error causes only SACK packet losses.
Besides a reliable transmission service, SCTP provides a partial reliable transmission service that is similar to UDP (user datagram protocol). This partial reliable transmission service is called the Part Reliability extension of the stream control transmission protocol [11]. PR-SCTP [12] applies partial reliable transmission to transmit SIP messages.
There have been some studies on SCTP focused on improving the applied performance. From the application perspective, using HTTP (hypertext transfer protocol) over the SCTP multistream service reduces the lengthy mean response time that results from TCP’s head-of-line blocking problem. Lee et al. [13] used an analytical model to compare the mean response time of both HTTP over TCP and HTTP over SCTP in wireless networks. Caro et al. [14] used the multiple fast retransmit algorithm as a retransmission strategy to reduce the number of timeouts to improve the performance. Kim et al. [15] proposed an efficient file transfer system using the SCTP multiple file transfer and modified SCTP congestion control mechanism to solve the problems such as server overloading due to multiple connection and the HOL (Head-Of-Line) blocking that exists in TCP-based file transfer. These studies mainly focused on using SCTP instead of TCP to improve application performance but were not concerned about the SCTP operation mechanism details that our study addresses.
The original SCTP path management judges a path failure only depending on consecutive transmission timeouts. This simple criterion, however, does not consider packet errors and hence possibly misjudge the path condition in a wireless environment. Furthermore, the SCTP prefers only the primary path, which is default but may not have better transmission efficiency comparing with other paths in the use of multiple wireless interfaces and multihoming. Therefore, we proposed QA-SCTP (quality-aware SCTP) to enhance the SCTP operation mechanism to improve performance.
3. SCTP Path Management
As stated in the introduction, SCTP multihoming can apply different destination IP addresses to establish independent associations simultaneously. To achieve this, SCTP defines a path management mechanism to ensure that transmission is performed successfully. However, the original mechanism still has some drawbacks for wireless networks that we describe later.
SCTP Original Path Failure Detection Mechanism
The SCTP management mechanism is based on the path failure mechanism. In Figure 1, when two endpoints establish associations, SCTP sets an error counter for each path and triggers these counters with packet timeouts. Conversely, the transmitter transmits data or heartbeat packets to the receiver. The packet timeout is measured, and the counter is incremented by 1 if the transmitter does not receive the response.
Figure 1: SCTP path failure detection mechanism.
Standard SCTP does not support concurrent multi-path transmission per association. SCTP packet transmission is performed through a single path only (primary path), while the other paths are alternative paths. SCTP marks each newly created path as “active” and applies the error count to monitor the path condition. If the error count reaches the inactive threshold, then SCTP changes the state to “inactive.” SCTP does not use any path marked as “inactive” for data transmission. The primary path error count algorithm is given as follows.(i)When SCTP is initiated, the error count value is zero and the path condition is “active.” The counter value is incremented by 1 each time a packet transmission for a path times out. The path condition for “inactive” activates when the counter value exceeds the value of Path_Max_Retrans.
(ii)If the transmitter receives the SACK sent by the receiver, then the transmission is successful and the error count returns to zero. The path is then changed from “inactive” to “active.”
Idle Path error count algorithm is given as follows.(i)The counter is incremented by 1 after the heartbeat packet is transmitted in an idle path if the transmitter does not receive a response in time and the path is not “inactive.” If error_counter_value > Path_Max_Retrans, then the path status is changed to “inactive.”
(ii)If the transmitter receives HEARTBEAT-ACK, then the counter value is changed to zero and the path status is changed from “inactive” to “active.”
The SCTP original path failure detection mechanism must take continuous packet timeouts to reach the inactive threshold. If a packet transmission includes any packet that is transmitted successfully before reaching the inactive threshold, then the error count is reset to zero. This mechanism, which is called the single sampling mechanism, easily detects a single failure that occurs occasionally, such as network outage. This mechanism can only detect continuous long-term path errors.
The time required to deactivate a path is more than s (when Path_Max_Retrans = 5 and RTO = 2 s) [10]. If packet transmission is successful during this period, then the error count is cleared and the process takes more than 62 s.
Figure 2 depicts a path with 23 packet timeouts occurring within 30 s of packet transmission. This path should not be used for data transmission due to the large number of packet errors in such a short time. However, the path does not reach the SCTP (RFC4960) inactive threshold, and, therefore, it is erroneously marked as “active.”
Figure 2: Original count algorithm leading to a mistaken evaluation of the path condition as active.
When the path error type is a short-term error with high frequency, the existing SCTP mechanism cannot work successfully. This causes erroneous path condition estimates for the wireless network.
4. Quality-Aware SCTP Path Management
The purpose of this study is to improve path management in SCTP for wireless networks. A whole-path management mechanism called quality-aware SCTP is proposed and is depicted in Figure 3. The proposed mechanism has three parts: path condition measurement, path switching strategy, and path switch decision. These can all help improve the original SCTP path management mechanism.
Figure 3: Quality-aware SCTP path management mechanism.
4.1. Path Condition Measurement
The path condition measurement mechanism monitors every path’s transmission condition to provide additional path information for path switching. The mechanism has three parts: the original SCTP’s heartbeat to measure the basic facets of the path condition, a smart path failure detection method, and path quality estimation.
4.1.1. Smart Path Failure Detection Method
This study proposes a new path failure detection method that applies a cycle count that can distinguish different levels of a timed out packet, which solves the defect of the original SCTP’s single count as shown in Figure 4.
Figure 4: Quality-aware SCTP path failure count method.
The proposed method counts the number of timeouts in a large number of transmissions, which is called the cycle count. In addition, SCTP has a backoff mechanism, in which a packet timeout results in retransmission and double RTO. Therefore, the proposed mechanism distinguishes different levels of timeout just like continuous or random timeouts in the cycle count.
The proposed method applies the different timeout cost of each counted error to represent different levels of timeout computed with a power function. The cost varies according to the length of timeout. Since transmission timeout interval increases by power of two in the SCTP mechanism, our method also increases the cost by power of two to reflect different levels of timeout. Therefore, the path reaches the inactive threshold quickly when a long-term error occurs on the path, as in the original method. The proposed method also causes a path with many short-term errors to reach the inactive threshold, which the original method does not do:(1)
The smart path failure detection mechanism computes the cost of any packet timeout by power weighting and adds this cost to the error counter. The power weighting can emphasize the burst error condition, which often occurs during handoff and briefly impairs transmission conditions. Standard SCTP does not always detect burst errors because they only produce a few errors, meaning that the error counter is not likely to reach the threshold. However, power weighting prevents this situation. If the total value reaches the threshold, then the path is marked “inactive” to prevent it from being further used by SCTP. The error count is returned to zero in two cases: when the path condition reaches the inactive threshold and when the number of successful packet transmissions reaches the count cycle.
4.1.2. Path Quality Estimation
In this part, we propose the ICE (idle path congestion window size estimation) mechanism for probing the path transmission conditions. By comparing the transmission conditions for the primary and secondary paths, the SCTP path management mechanism can choose the stable path with better transmission efficiency.
The path for a multinetwork environment is generally chosen according to bandwidth [16]. For protocols such as SCTP or TCP, the number of transmission packets in the transmission process is determined by the protocol’s sliding/congestion window (cwnd). Therefore, measuring the bottleneck bandwidth is not the key point. Even if a high-bandwidth network is applied, it might not be usable since the transmission efficiency is determined by cwnd.
The congestion window size in the SCTP congestion control mechanism is linked to the transmission condition. If the packet times out frequently, then the congestion window size must remain small. The congestion control mechanism can be applied to measure the changing of the congestion window size for the transmission path based on packet losses. Therefore, the efficiency when SCTP uses that path can be derived. Additionally, the SCTP evaluation criteria for path selection must be modified from the bottleneck bandwidth in the network to whether the cwnd size is stable. A more stable path leads to higher transmission efficiency.
However, since SCTP multihoming is built by independent paths connected through different IP addresses, each path has an independent congestion mechanism to control the number of packets. Because packets are transmitted along the primary path, changes in the congestion window size can be detected by directly monitoring the transmission condition of the data packets. Moreover, packets need to be produced and sent along alternative paths to detect changes in the size of each congestion window.
Data packet transmission on idle paths is simulated with the heartbeat mechanism. Heartbeat packets are enlarged to simulate real data packets; their packet type is changed to discriminate data packets for probing, and the sequence numbers of the packets are filled in the idle column. The transmission condition is determined from the packet sequence numbers.
After the idle path transmits a mass idle path congestion window size estimation packet, the changing conditions of the congestion widow size in these paths are estimated from the packet receiving condition.
To prevent too many ICE packets from destroying the overall network condition, they are measured periodically to estimate the changing value of the congestion window size. We set the ICE measurement as periodic in the experiment. The original heartbeat mechanism was applied for the remainder of the time to measure the basic path condition (active/inactive).
The packet transmission quantity for ICE was set as equal to the primary path’s packet transmission quantity for fairness and to make the estimation worthwhile. As ICE initiates and starts to transmit packets on the idle path, ICE mechanism obtains the transmission conditions for the primary path by observing current congestion window size. In other words, the two paths have the same number of packets, and their packet transmission conditions are estimated for the same time period. The path condition for an idle path can be accurately estimated with this approach, as shown in Figure 5.
Figure 5: ICE mechanism: ICE operation graph.
4.2. Path Switch Strategy
In the path quality estimation mechanism, ICE periodically measures the congestion window of each path to identify the best path. If the idle path has a larger mean congestion window size than the primary path, then the transmission path needs to change to the idle path (secondary path) to improve the transmission efficiency as shown in Figure 6.
Figure 6: Path quality estimation and ICE mechanism pseudo code on the primary and secondary paths.
A better understanding of the path condition makes choosing a suitable path easier. Therefore, more realistic modeling of the path condition can enhance the performance of SCTP. However, standard SCTP only knows the availability of paths (i.e., heartbeat) and not their available bandwidth. Therefore, this study proposes that ICE should obtain the condition of idle paths. ICE can periodically measure the bandwidth with the congestion window method as in ordinary SCTP transmissions and can also model the available bandwidth of alternative paths for times when an alternative path becomes a better choice than the primary path. Knowing the path condition is essential for the quality-aware SCTP path management mechanism. If the path condition is measured inaccurately, then incorrect path switching decisions may be taken. Therefore, obtaining accurate path conditions and reducing the error path information are very important.
The measurement mechanism is based entirely on the path condition and detects heartbeat and path failure from timeout errors for packet transmission as shown in Figure 7. The ICE mechanism we proposed is like other bandwidth estimation methods in that the more time it operates the more data it has to estimate conditions.
Figure 7: (a) and (b) Primary path, (c) and (d) Secondary path. Path failure detection mechanism pseudocode.
4.3. Path Switch Decision
By enhancing the original SCTP, quality-aware SCTP can decide whether to change paths based on known information. The path condition measurement provides every path’s transmission condition, and the path switching strategy provides the methodology. When the primary path’s condition is unstable or degenerates, quality-aware SCTP transmits data along an alternative path.
5. Simulation
We studied the performance of the proposed scheme via simulation by using ns-2.29 and SCTP modules [17].
5.1. Packet Loss Model for Wireless
Packet losses in wireless networks often result from a user moving out of range of the signal, interference from other signals, or handoff. Wireless channel errors can easily occur due to continuous interference over a short period. For example, data cannot be sent to or from a channel due to continuous interference. Because the random error model does not have the necessary features to simulate this condition in a wireless network simulation, the burst error model was used to ensure that the simulation accurately mirrored real-world situations.
Burst loss in wireless networks can be modeled as a continuous two-state alternating Markov chain. The duration for the good and bad states was independently and identically distributed with an exponential distribution function using the mean G/B [3, 9].
The network link had 1% random loss rate in the good state and 100% random loss rate in the bad state. The transmission medium was fully loaded in both good and bad states. The network total packet loss rate was defined as (neglecting 1% random loss in the good state) (2)
5.2. Experiments
5.2.1. Experiment 1: Quality-Aware SCTP Path Failure Detection Method
The path failure detection mechanism in standard SCTP can only detect continuous long-term errors. Although frequent short-term errors can make the path conditions not good enough for data transmission, this would not be detected by the standard SCTP mechanism. Therefore, standard SCTP can produce erroneous decisions for wireless networks. This study proposes a new path detection mechanism that measures the defects in terms of count cycle. Experiments were performed to test the proposed method.
Figure 8 depicts a mixed wired-wireless topology. Each mobile node has two wireless network interface cards connected to AP1 (802.11b) and AP2 (802.11b). The pre-set path failure judgment threshold was set to 15% packet loss rate, and the count cycle was set to 220 successful packet transmissions, as mentioned in Figure 7(a). A path was marked as “inactive” if its packet loss rate was 15%. The experiment parameter is shown in Table 1.
Table 1: Parameters of experiment. Figure 8: Quality-aware SCTP Path failure detection mechanism experiment topology.
Figure 9 depicts a simulation in which the packet loss rate for Path 1 was set to 30%. The original and proposed SCTP path failure detection mechanisms detected the deterioration of Path 1’s condition in 197.671 and 159.498 s, respectively.
Figure 9: QA-SCTP Path failure detection mechanism experiment (with 30% bit error rate).
In this simulation (Figure 9), both methods identified the poor condition of Path 1; however, the proposed mechanism did so more quickly than the standard SCTP. The proposed method switched to Path 2 rapidly and had a throughput about 40% greater than RFC4960 within 200 s. Table 2 lists the related experimental data.
Table 2: Experimental data for quality-aware SCTP path error detection mechanism.
5.2.2. Experiment 2: Impact of Network Condition on Transmission Efficiency
Both TCP and SCTP control congestion by changing the congestion window size to control the quantity of packets being transmitted. In addition, the packet transmission condition affects the size of the congestion window [1, 18]. Therefore, the packet transmission condition (i.e., packet loss rate/network congestion condition) can be used to measure the approximately SCTP packet flow and thus identify the best SCTP path.
This experiment was performed in two parts. Part 1 simulated frequent packet loss, causing the congestion control mechanism to decrease the congestion window size, which degraded the transmission efficiency.
Figure 10 depicts the experiment topology, which was based on a combined wired and wireless network. Each MN had a wireless NIC connected with AP for an 802.11b wireless network. Both CN and MN had one NIC and therefore had only one transmission path. Nodes 1 and 2 were the other nodes in the path.
Figure 10: Impact of network condition on transmission efficiency of experimental topology.
Figure 11 shows that a higher packet loss rate reduces the congestion window size and lowers the throughput of the overall transmission. The values 11, 6, and 2 MB stand for the physical data rate for the IEEE 802.11 channel (11, 6, and 2 Mbits per second, resp.). An excessive network error rate would thus result in unacceptably low transmission efficiency even with abundant bandwidth. Thus, the wireless bandwidth, which is usually a bottleneck in a network, is not the only factor to influence throughput and transmission efficiency over loss-prone channels.
Figure 11: Impact of packet loss rate on transmission efficiency.
In part 2, the impact of network congestion on both the congestion window size and transmission efficiency was observed. Traffic at a CBR (constant bit rate) was added between Nodes 1 and 2 to simulate the network congestion.
Figure 12 shows that wired network congestion did not affect the overall transmission condition when CBR MB. (At this condition, the transmission bottleneck relies on wireless bandwidth, not on the congestion of the wired network.) However, the network became severely congested when CBR MB. The congestion reduced the SCTP packet transmission efficiency and caused some packet timeouts. Therefore, the growth rate for the congestion window slowed down. This experiment identified the relationship between congestion in the network and congestion window size. A congested path is identified from the degree of congestion in the congestion window (cwnd).
Figure 12: Impact of path congestion on SCTP cwnd/throughput.
5.2.3. Experiment 3: Quality-Aware SCTP Path Condition Measure/Switch Experiment
Path management in SCTP applies multihoming to select the best path from all paths with the ICE mechanism (QA-SCTP). In the primary path, data packets are used to estimate the condition of path, while measuring packets are actively sent along the secondary path to measure the transmission conditions. The best path for transmitting data is determined from the conditions of the two paths. Experimental results show that the proposed QA-SCTP (quality-aware SCTP) path management mechanism assesses the path condition accurately and changes paths smoothly, thus providing high transmission efficiency.
As depicted in Figure 13, a simple multihoming experiment environment was deployed; Path 1 and Path 2 had different network conditions (using the burst error model in Section 5.1). The parameters of the ICE mechanism in QA-SCTP were set to a period of 100 s and a duration of 30 s; a longer ICE duration results in a more accurate measurement of the path condition, but it may result in additional loading when the ICE operating time is too long, thus causing too many measuring packets to be transmitted.
Figure 13: QA-SCTP path condition measure/switch experiment topology.
Experimental results show that QA-SCTP measured the path condition accurately. Figure 14(a) indicates that although data were transmitted on the bad path at the start of the connection, QA-SCTP changed paths to increase transmission efficiency at 134.38 s since the ICE mechanism found that Path 2 had better conditions than Path 1 at that moment.
Figure 14: QA-SCTP path condition measure/switch experiment results.
According to Figure 14(b), although Path 2 had a narrower bandwidth than Path 1, it enabled the congestion window size to grow stably, thus reducing the packet loss rate and increasing the efficiency. Table 3 lists the experiment results.
Table 3: QA-SCTP path condition measure/switch experiment results list.
5.2.4. Experiment 4: Dynamic PLR Conditions
In the following experiment depicted in Figure 15, the path condition changes continuously. Path 2 was set as the primary path for default transmission. In Figure 16, the red line (QA-SCTP Path 2) denotes the graph of QA-SCTP with the ICE mechanism; the green line (RFC4960-Path 2) denotes the results for SCTP in the same environment; and the blue line (RFC4960-Path 1) denotes the results for SCTP with Path 1 as the primary path (for comparison). In this experiment, QA-SCTP was set up with Path 2, which was the worse path, as the primary path. The path was changed at 31.61 s. QA-SCTP recognized changes to the path condition and changed to a better transmission path, as shown in Table 4.
Table 4: QA-SCTP path condition measure/switch experiment data. Figure 15: QA-SCTP path condition measure/switch experiment topology. Figure 16: QA-SCTP path condition measure/switch experiment result.
5.2.5. Experiment 5: Dynamic Parallel Congestion Conditions
As shown in Figure 15, the following experiment was performed to demonstrate QA-SCTP actively changing paths in a congested network. Two CBR connections were set up—one between Nodes 1 and 2 (CBR 8 MB at 50–250 s) and another between Nodes 3 and 4 (CBR 3 MB at 70–300 s)—to simulate congestion.
In Figure 17, the red line denotes the throughput measured from QA-SCTP in Paths 1 and 2 with 11 MB bandwidth; the green line denotes the throughput measured from QA-SCTP in Path 1 with 11 MB bandwidth and Path 2 with 6 MB bandwidth; and the blue line denotes the throughput measured from the SCTP (RFC4960) in Paths 1 and 2 with 11 MB bandwidth. According to Figure 17, the transmission efficiency of the primary path degraded because of congestion after 50 s. Therefore, QA-SCTP (red line) changed paths at 149.13 s and achieved better throughput than SCTP (RFC4960). In addition, QA-SCTP (green line) changed paths at 134.4 s. Thus, QA-SCTP achieved a better throughput than SCTP (RFC4960) in a congested network despite changing the transmission path to Path 2, which had a bandwidth of only 6 MB.
Figure 17: QA-SCTP path condition measure/switch experiment result.
5.2.6. Experiment 6: Dynamic Disjunct Congestion Conditions
In the following experiment, as shown in Figure 15, congestion occurring at different times in the two paths was simulated (Path 1 was congested at 100–250 s; Path 2 was congested at 250–400 s). In Figure 18, the red line denotes the throughput measured from the QA-SCTP environment with Path 1 as the primary path; the green line denotes the throughput measured from the SCTP (RFC4960) environment with Path 1 as the primary path; and the blue line denotes the throughput measured from the standard SCTP environment with Path 2 as the primary path.
Figure 18: QA-SCTP path condition measure/switch experiment result.
As shown in Figure 18 and Table 5, QA-SCTP actively changed the path to Path 2 because Path 1 became congested at 100 s (Path 2 was not congested) and changed back at 250 s because of congestion in Path 2 (Path 1 was less congested). QA-SCTP can change the current transmission path to a noncongested one quickly, thus improving the transmission efficiency.
Table 5: Experiment results for QA-SCTP path condition measure/switching.
6. Conclusion
The SCTP multihoming method supports multipath association, which enhances network transmission performance. SCTP supports multihoming and develops an original transmission performance. The path failure detection mechanism requires suitable path management in a wireless network. A good path management approach effectively distinguishes path conditions (e.g., active or inactive) and efficiently switches among multiple destination addresses (e.g., active or passive path switching).
The original path management method for SCTP that is defined in RFC4960 is very simple but does not effectively distinguish path conditions (e.g., active or inactive) or efficiently apply multiple destination addresses in wireless networks.
This study proposes a new and effective path management mechanism for wireless networks called quality-aware SCTP. This mechanism uses cycle counting—rather than single counting as in standard SCTP—to detect path failures. Cycle counting improves on the original path failure detection method in a wireless environment because it effectively identifies the path condition. The ICE mechanism in QA-SCTP can effectively estimate the path quality and provides information for path switching decisions. Experimental results under NS2 demonstrated that QA-SCTP performs better than standard SCTP, because it actively switches when the primary path is still active and passively switches when the path condition deteriorates and is inactive.
Other studies use complicated methods to adjust the congestion window size in a wireless environment to increase throughput. This study focuses on effectively identifying path conditions. Effectively identifying the path conditions enables the mechanism to rapidly switch to a secondary path when the primary path has a serious error or is in poor condition. Quality-aware SCTP not only is simple but also improves performance.
7. Future works
The ICE mechanism in QA-SCTP can effectively estimate the path quality but needs to transmit many estimation packets, thus wasting wireless network resources. Further works will include improving the technique for estimating path quality to decrease the number of estimation packets used by the idle path, implementing a prototype of proposed SCTP modification, and further discussion on the effect of mobility in wireless domain.
Saturday, June 26, 2010
Thursday, May 13, 2010
Low Signal Strength Analysis
Low Signal Strength Analysis
Low Signal strength is one of the reason of drop call. It can be indicated by many calls disconnected at low signal strength by subscriber, drop calls due to excessive TA, poor handover performance and poor call setup performance.
Probable Reason
Poor BSC Exchange Property setting High LOWSSDL & LOWSSUL will give more drop reason due to SS and this might not show the actual drop. It is because drop due to SS is more priority than Quality.
No dominant cell Cell might be isolated or standalone.
Antenna tilt & orientation Too much downtilt sometimes might not cover a larger area and the subscriber might lose the SS.
Output Power Low output power might cause smaller border cell.
The following procedure should be performed for low signal strength
analysis:
1:Identify the baseline requirement of design and BSC exchange property (setting for LOWSSUL/LOWSSDL).
2:Check the value for LOWSSDL & LOWSSUL. If it is higher than ACCMIN, change the parameter to a reasonable value since the drop reason will be more priority to SS compared to Quality.
3:Check the site position, antenna direction, position etc. This is to ensure the possible location is open to interference (open water environment) or isolated. Good map is needed for this.
4:Check if the site is sectorized or Omni. If it is Omni, set the cell into sectorized cell.
5:Check if the signal strength is uplink or downlink limited. Mostly, It is designed to be downlink limited.
6:Check the coverage cover expected area from the planet. If it is not, check the antenna tilt and orientation. Change the direction or tilt if it is too much downtilt or pointing to a wrong direction.
7:Sometime, low output power might cause low SS. Check output power and if it is low, increase the output power.
8:Check cell whether it has hotspots from drivetests. If found, adding new site is recommend.
9:In order to check power distribution, run Cell Traffic Recording (CTR) to that particular cell.
10:Check if the cell has indoor coverage problem. If yes, add micro site instead.
Probable Reasons of SDCCH Congestion
---Low Availability
Action: Check SDCCH Availability. Check if the channels are manual, control or automatic blocked.
---Increasing Traffic Demand
The high traffic could be related to an occasional event or due to a long term growth.
Action: Check if short term traffic growth. Make trend comparisons. Check if combined SDCCH is used. Check SDCCH dimensioning.
---Bad use of Adaptive configuration of Logical Channels
By using the Adaptive configuration of logical channels feature, the basic SDCCH configuration in a cell will be under-dimensioned. If this feature is not used correctly, it will cause SDCCH congestion.
Action: Check if ACSTATE is on. Check parameters related to Adaptive configuration of logical channels
---Long Mean Holding Time
If the mean holding time is long, this generates a higher traffic load.
Action: Check SDCCH Mean Holding Time
---Too Frequent Periodic Registration
Action: Check Random Access Distribution. Check the timer T3212 in the BSC and the parameters
---BTDM and GTDM in the MSC
Solution: Decrease the periodic registration.
---Location Area Border Cell
If the cell is situated on a misplaced Location Area border, this means that unnecessary many normal LUs are performed.
Action: Check site position and location area border. Check Location Update Performance. Check parameter CRH etc.
---Extensive SMS Usage
Extensive SMS usage increases the SDCCH traffic and could cause congestion if badly dimensioned SDCCH channels.
Action: Check SMS activity.
---Cell Broadcast Used
Action: Check if Cell Broadcast is active. .If active, check if it is used by the operator.
---IMSI Attach/Detach in Use.
An introduction of IMSI attach/detach will increase the traffic on SDCCH. However, the benefits are that the paging success rate will increase. The recommendation is to use Attach/Detach.
---Cell Software File Congestion
Action: Check SAE setting. High Ratio of Random Accesses
Action: Check Random Access performance
Probable Reasons of Bad Handover Performance
---Neighboring Cell Relation
Action:Add neighbor cell relation.
---Missed measurement frequencies in BA-list
Action:Check measurement frequencies list.
---Permitted Network Color Code problem
Action:Check NCC Permitted
---HW faults.
Action: Check BTS error log.
---Blocking on Target Cell
Action:Remove Blocking on Tager Cell
---Congestion
A high congestion might lead to dragged calls (handover performed at a not intended location) and a lot of unsuccessful handovers.
Action: Check TCH congestion.
---Timer Expire After MS is Lost
The MS never answers the base station.
Action: Check coverage. Check interference.
---Link Connection or HW Failure
Action: Check BTS error log. Perform site visit. Perform link performance measurements.
---Bad Antenna Installation
Action: Perform site survey and check antenna installation. Check antenna cabling.
---Many Neighbors Defined
Many defined measurement frequencies defined (>16) will decrease the accuracy of the mobile measurements to locate the best six servers. Many measurement frequencies mean few samples per frequency and problem for mobiles to decode the BSIC.
Action: Check number of definitions.
---Delayed Handover Decision
A delayed handover decision can be due to congestion in the target cell.
Action: Check handover parameters.
---Wrong Locating Parameter Setting
Action: Check locating parameters.
---Bad Radio Coverage
Action: Check coverage plots.
---High Interference, Co-Channel or Adjacent
The potential handover candidate is disturbed by interference. Outgoing handover due to bad uplink quality may indicate interference from co-channel another MS. On the border, the quality may be rather bad and the signal strength low. Bad downlink quality may indicate interference from another co-channel base station.
Action: Check interference. Check if many handovers are performed due to downlink or uplink bad quality.
---Receiver Antenna Problem or RBS HW problems (in candidate cell)
Action: Check antenna installation. Check RBS HW and Error log of the target cell
---Poor Inter-MSC/BSC Handover Performance
For outer or external cell, wrong definitions in either MSC or BSC may be reason for the problem.
Action: Check inter-MSC/BSC handover performance.
---Incorrect Down Tilt
Action: Perform site survey and check antenna installation.
Solution: Correct antenna tilting.
Action:Add neighbor cell relation.
---Missed measurement frequencies in BA-list
Action:Check measurement frequencies list.
---Permitted Network Color Code problem
Action:Check NCC Permitted
---HW faults.
Action: Check BTS error log.
---Blocking on Target Cell
Action:Remove Blocking on Tager Cell
---Congestion
A high congestion might lead to dragged calls (handover performed at a not intended location) and a lot of unsuccessful handovers.
Action: Check TCH congestion.
---Timer Expire After MS is Lost
The MS never answers the base station.
Action: Check coverage. Check interference.
---Link Connection or HW Failure
Action: Check BTS error log. Perform site visit. Perform link performance measurements.
---Bad Antenna Installation
Action: Perform site survey and check antenna installation. Check antenna cabling.
---Many Neighbors Defined
Many defined measurement frequencies defined (>16) will decrease the accuracy of the mobile measurements to locate the best six servers. Many measurement frequencies mean few samples per frequency and problem for mobiles to decode the BSIC.
Action: Check number of definitions.
---Delayed Handover Decision
A delayed handover decision can be due to congestion in the target cell.
Action: Check handover parameters.
---Wrong Locating Parameter Setting
Action: Check locating parameters.
---Bad Radio Coverage
Action: Check coverage plots.
---High Interference, Co-Channel or Adjacent
The potential handover candidate is disturbed by interference. Outgoing handover due to bad uplink quality may indicate interference from co-channel another MS. On the border, the quality may be rather bad and the signal strength low. Bad downlink quality may indicate interference from another co-channel base station.
Action: Check interference. Check if many handovers are performed due to downlink or uplink bad quality.
---Receiver Antenna Problem or RBS HW problems (in candidate cell)
Action: Check antenna installation. Check RBS HW and Error log of the target cell
---Poor Inter-MSC/BSC Handover Performance
For outer or external cell, wrong definitions in either MSC or BSC may be reason for the problem.
Action: Check inter-MSC/BSC handover performance.
---Incorrect Down Tilt
Action: Perform site survey and check antenna installation.
Solution: Correct antenna tilting.
Dropped Call(TCH Drop-SDCCH Drop)-TCH Drop Analysis
Step to check TCH Drop Analysis.
1. Radio Link Time-Out
Every time a SACCH message can not be decoded the radio link time-out counter is decreased by 1. If the message can be decoded the counter is incremented by 2. However, the value can not exceed the initial value. The initial value is set by the parameter RLINKT for radio link time-out in the mobile station and by RLINKUP for timeout in the BSC. If the mobile moves out of coverage and no measurement reports are received in the BSC, there will be a radio link time-out and the message Channel Release (cause: abnormal release, unspecified) is sent to the mobile station and the SACCH is deactivated in the BTS. A Clear Request message is sent to the MSC. To be sure that the mobile has stopped transmitting, the BSC now waits RLINKT SACCH periods before the timeslot is released and a new call can be established on the channel.
2. Layer 2 Time-Out
If the BTS never get an acknowledge on a Layer 2 message after the time T200XN200, the BTS will send Error Indication (cause: T200 expired) to the BSC, which will send Channel Release (cause: abnormal release, timer expired) to the mobile station and a Clear Request to the MSC. The SACCH is deactivated and the BSC waits RLINKT SACCH periods before the timeslot is released and a new call can use the channel. This is only valid if the call is in steady state, i.e. not during handover or assignment.
3. Release Indication
When the BTS received a layer 2 DISC frame from the mobile it replies with a Layer 2 UA frame to the mobile station and a Release Indication to the BSC. The system does only react on Release Indication if it is received during a normal disconnection situation. If such a message is received unexpectedly this will usually cause radio link time-out or timer T200 expiration as the mobile station stops the transmitting of measurement reports. It is also possible that the release will be normal depending on when the Release Indication is received.
4. MSC Time-Out
Normal Release:
If the MSC never received a response on a message (e.g. Identity Request) and there is no radio link time-out or layer 2 time-out, the MSC will send a Clear Command to the BSC. The time-out is depending on the message. When receiving Clear Command, the BSC will send a Channel Release (cause: normal release) and then deactivates the SACCH.
Reject (only SDCCH):
If the MSC never receives a response on the first message after Establish Indication, the MSC will send a reject message. If the connection was a Location Update it will be a Location Update Reject (cause: network failure) and if the connection was a mobile originating call (CM Service Request) a CM Service Reject (cause: network failure) will be sent. The MSC will then send a Clear Command to the BSC and the call is cleared by Channel Release (cause: normal release).
5. Assignment to TCH
Before sending an Assignment Command from the BSC at TCH assignment, the following two criterion have to be fulfilled:
a. There must be a TCH channel available, i.e. no congestion
b. The locating algorithm must have received at least one valid measurement report.
If either of the criterion is not fulfilled, Assignment Command will not be sent and a Channel Release (cause: abnormal release, unspecified) will be sent to the mobile station and a Clear Request to the MSC.
TCH Drop reason (1)
The classification of TCH Drop Reasons are arranged in the order of priority:
1.Excessive Timing Advance
2.Low Signal Strength
3.Bad Quality
4.Sudden Loss of Connection
5.Other Reasons
Excessive Timing Advance
The TCH Drop counters due to Excessive Timing Advance will pegged when the during the time of disconnection, the last Timing Advance value recorded was higher than the TALIM Parameter. This drop reason is commonly apparent to isolated or island sites with a wide coverage area.
Action:
Check if the cell parameter TALIM is < "63"
Solution:
Set TALIM to a value close to 63.
Tilt antenna/reduce antenna height/output power, etc. for co-channel cells.
TCH Drop Reasons (2)
Low Signal Strength on Down or Uplink or Both Links
The drops counters due to Low Signal Strength will be pegged when the Signal Strength during the last Measurement Report before the call dropped is below the LOWSSDL and/or LOWSSUL Thresholds. LOWSSDL and LOWSSUL are BSC Exchange Property parameters which is used only for statistics purposes and does not affect the behavior of calls. If both UL and DL Signal Strength are below the thresholds, only Drop due to Low SS BL will pegged. Normally a call is dropped at the border of large rural cell with insufficient coverage. Bad tunnel coverage cause many dropped calls as well as so called coverage holes. Bad indoor coverage will result in dropped calls. Building shadowing could be another reason.
Action:
Check coverage plots.
Check output power.
Check power balance and link budget.
Check if Omni site.
Check antenna configuration & type.
Check antenna installation.
Perform drive tests & site survey.
Check TRX/TS with high CONERRCNT.
Solution:
Add a repeater to increase coverage in for example a tunnel.
Change to a better antenna (with higher gain) for the base station.
Add a new base station if there are large coverage holes.
Block/Deblock TRX
TCH Drop Reasons (3)
Poor Quality on Down or Uplink or Both Links
The drops counters due to Bad Quality will be pegged when the Signal Strength during the last Measurement Report before the call dropped is above the BADQDL and/or BADQUL Thresholds. BADQDL and BADQUL (expressed in DTQU) are BSC Exchange Property parameters which is used only for statistics purposes and does not affect the behavior of calls. If both UL and DL Quality are above the thresholds, only Drop due to BAD Quality BL will pegged.
Problem on Bad Quality is usually associated with Co-channel Interference on BCCH or TCH. Faulty MAIO assignment can cause frequency collisions on co-sited cells especially on 1x1 Reuse. External interference is also one possible cause of problem on quality.
Action:
Check C/I and C/A plots.
Check Frequency Plan (Co-BCCH or Co-BSIC Problem).
Check MAIO, HOP, HSN parameters.
Check FHOP if correctly configured (BB or SY).
Check for External Interference.
Perform drive tests.
Solution:
Change BCCH frequency.
Change BSIC.
Change MAIO, HOP, HSN.
Change FHOP.
Record RIR or on-site Frequency Scanning to identify source of interference.
Use available radio features.
TCH Drop Reasons (4)
Sudden Loss of Connection
Drops due to Sudden Loss are drops that have not been registered as low signal strength, excessive timing advance, bad quality or hardware (other) reasons, and the locating procedure indicates missing measurement results from the MS.
There are some common scenarios that could lead to Sudden Loss of connections such as very sudden and severe drops in signal strength, such as when subscribers enter into buildings, elevators, parking garages, etc., very sudden and severe occurrence of interference, MS runs out of battery during conversation, Handover Lost, BTS HW faults, Synchronization or A-bis link fault (transmission faults), and
MS Faults.
Action:
Check BTS Error Logs, Alarms and Fault Codes.
Check CONERRCNT per TRX and TS.
Check Transmission Link (A-bis).
Check for DIP Slips.
Check LAPD Congestion.
Correlate Handover Lost to Drops due to Sudden Loss
Solution:
Fix Hardware Faults and Alarms.
Reset TRX with high CONERRCNT.
Ensure that Synchronization and A-bis Link are stable.
Change RBLT with high DIP Slips.
Change CONFACT or increase Transmission Capacity
Investigate HO Lost Problem
TCH Drop Reasons (5)
TCH Drops due to Other Reasons
TCH drops due to Other Reasons are computed by subtracting the sum of drops due to Excessive TA, Low SS, Bad Quality and Sudden Loss from the Total TCH Drop Counts. Drops due to Other Reasons are generally associated with hardware problems, transmission link problems on A-bis, Ater or Ainterfaces, and sometimes Handover Lost.
Action:
Check BTS Error Logs.
Check Alarms and Fault Codes.
Check CONERRCNT per TRX and TS.
Check Transmission Link (A-bis).
Check for DIP Slips.
Correlate Handover Lost to Drops due to Other Reasons
Solution:
Fix Hardware Faults and Alarms.
Reset TRX with high CONERRCNT.
Ensure that Synchronization and A-bis Link are stable.
Change RBLT with high DIP Slips.
Investigate HO Lost Problem
Problem reason of drop in SDCCH
Low Signal Strength on Down or Uplink
The reason for poor coverage could be too few sites, wrong output power, shadowing, no indoor coverage or network equipment failure.
Action: Check coverage plots.Check output power. Perform drive tests. Check BTS error log
Solution: Add new sites. Increase output power. Repair faulty equipment.
Poor Quality on Down or Uplink
Action: Check C/I and C/A plots. Check frequency plan. Perform drive tests.
Solution: Change frequency. Use available radio features.
Too High Timing Advance
Action: Check if the cell parameter TALIM is < style="font-weight: bold;">Solution: Set TALIM to a value close to 63. Tilt antenna/reduce antenna height/output power, etc. for cochannel cells.
Mobile Error
Some old mobiles may cause dropped calls if certain radio network features are used. Another reason is that the MS is damaged and not working properly.
Action: Check MS fleet.
Solution: Inform operator.
Subscriber Behavior
Poorly educated subscribers could use their handsets incorrectly by not raising antennas, choosing illadvised locations to attempt calls, etc.
Action: Check customer complaints and their MS.
Battery Flaw
When a subscriber runs out of battery during a conversation, the call will be registered as dropped call due to low signal strength or others.
Action: Check if MS power regulation is used. Check if DTX uplink is used.
Congestion on TCH
The SDCCH is dropped when congestion on TCH.
Action: Check TCH congestion
Solution: Increase capacity on TCH or using features like Assignment to another cell, Cell Load Sharing, HCS, Dynamic Half-Rate Allocation and FR-HR Mode Adaptation etc
T3103 and T3105 differences?
Timer rr_t3103 (0-1000000, default 5000) used to determine switching dropped calls. Upon receipt of the target cell's switching success message or the source cell switching unsuccessful information, rr_t3103 will stop the clock. Upon receipt of the target cell's switching success message or the source cell switching unsuccessful information, rr_t3103 will stop the clock. Otherwise, once rr_t3103 to time, notify the MSC, remove the connection, dropped calls switch occurred. Otherwise, once rr_t3103 to time, notify the MSC, remove the connection, dropped calls switch occurred.Timer rr_t3105, used when asynchronous cell switch, determine whether the time right before Timer physical information (Physical information) in the GSM system, switching process, the mobile station receive network switch command, sent to the target channel switch access (HANDOVER ACCESS) message. Timer rr_t3105, when used in asynchronous cell switch, determine whether the time right before Timer physical information (Physical information) in the GSM system, switching process, the mobile station receive network switch command, sent to the target channel switch access (HANDOVER ACCESS) message. Network receive the message, calculate the RF characteristics, means the unit of data sent to the mobile station physical information, and start the timer T3105 (GSM 4.08 specification is defined as the T3105, Ericsson system parameters defined as TIMER3105). Network receive the message, calculate the RF characteristics, means the unit of data sent to the mobile station physical information, and start the timer T3105 (GSM 4.08 specification is defined as the T3105, Ericsson system parameters defined as TIMER3105). If the T3105 has not yet received the mobile station sent out the correct layer 2, the network will be re-issued physical information, and restart the T3105. If the T3105 has not yet received the mobile station sent out the correct layer 2, the network will be re-issued physical information, and restart the T3105. Physical information up to the number of retransmissions by the parameter "maximum number of physical information repeated up to the number of retransmissions by the parameter" maximum number of times to repeat
When the network switch to send the mobile station received access message, physical channel to be essential to achieve synchronization status. When the network switch to send the mobile station received access message, physical channel to be essential to achieve synchronization status. As long as the communication channel quality can be guaranteed to receive the mobile station should be able to correct physical information, and to send a layer 2 network structure of the frame. As long as the communication channel quality can be guaranteed to receive the mobile station should be able to correct physical information, and to send a layer 2 network structure of the frame. If the physical information sent to the mobile station can not receive after the issue of layer 2, typically, poor quality physical channel can not carry out normal communication, the appropriate increase in the number of physical information re-issued, so that the quality of the physical channel network in the upturn issued by the mobile station receives the layer 2 frames to complete the switching process, thus avoiding unnecessary dropped calls. If the physical information sent to the mobile station can not receive after the issue of layer 2, typically, poor quality physical channel can not normal communication, the appropriate increase in the number of physical information re-issued to the network at the physical change for the better channel quality to the mobile station when the received level 2 issued to complete the switching process, thus avoiding unnecessary dropped calls.
Handover access failure due to dropped calls of the main reasons: Handover access failure due to dropped calls of the main reasons:
? lack of signal strength coverage unstable, MS can not be properly received. ? lack of signal strength coverage unstable, MS can not be properly received. This mostly occurs in the course of an emergency switch. This mostly occurs in the course of an emergency switch. Cause MS can not normally receive PHYS INFO message. Cause MS can not normally receive PHYS INFO message.
Wrong switch, as the services may exist around the two communities with the BCCH of the cell, resulting in the activation of another system error plot of the TCH, MS PHYS INFO message can not be correctly received. Wrong switch, as the services may exist around the two communities with the BCCH of the cell, resulting in the activation of another system error plot of the TCH, MS PHYS INFO message can not be correctly received.
At present most of the Ericsson system, network, T3105 and NY1 are using the system default settings, specific to TIMER3105 = 4 (40 ms), NOOFPHYSINFOMSG = 35 (35 times). At present most of the Ericsson system, network, T3105 and NY1 are using the system default settings, specific to TIMER3105 = 4 (40 ms), NOOFPHYSINFOMSG = 35 (35 times). For some of the more serious interference with the network (such as China Unicom Network GSM900 1 × 1), 40 ms latency and 35 times the weight obviously not the right hair, the light of experience appropriate to improve T3105 and NY1 (NOOFPHYSINFOMSG), can effectively reduce the switching in dropped calls occurred. For some of the more serious interference with the network (such as China Unicom Network GSM900 1 × 1), 40 ms latency and 35 times the weight obviously not the right hair, the light of experience appropriate to improve T3105 and NY1 (NOOFPHYSINFOMSG), can effectively reduce the switching in dropped calls occurred.
The direct cause of dropped calls, there are two: 1, RF loss. The direct cause of dropped calls, there are two: 1, RF loss. 2, switch dropped calls (Note: The switch failure does not mean dropped calls, switching failure> switch dropped calls). 2, switch dropped calls (Note: The switch failure does not mean dropped calls, switching failure> switch dropped calls). The following analysis of these two cases. The following analysis of these two cases.
(1) RF loss (1) RF loss
A. A. Failure specification defines the downlink, mobile Taichung timer S (T100), in the beginning of the call the mobile station is assigned an initial value, that is, the wireless link timeout (radio_link_timeout). Failure specification defines the downlink, mobile Taichung timer S (T100), in the beginning of the call the mobile station is assigned an initial value, that is, the wireless link timeout (radio_link_timeout). This value is broadcast in the BCCH. This value is broadcast in the BCCH. Whenever the mobile station can not correctly decode a SACCH message (4 SACCH BLOCK) time, S minus 1. Whenever the mobile station can not correctly decode a SACCH message (4 SACCH BLOCK) time, S minus 1. Whenever the mobile station correctly decode a SACCH message, S plus 2. Whenever the mobile station correctly decode a SACCH message, S plus 2. However, the definition of S does not exceed radio_link_timeout initial. However, the definition of S does not exceed radio_link_timeout initial. When the S count is zero, the mobile station to give up radio resource connection, enter the idle mode. When the S count is zero, the mobile station to give up radio resource connection, enter the idle mode. Occur once dropped calls. Occur once dropped calls.
B. B. Uplink uplink failure failure
System failed to monitor the parameters of the uplink is link_fail. System failed to monitor the parameters of the uplink is link_fail. When the base station can not correctly decode a SACCH message, HDPC in the counter (the maximum value defined by the link_fail) minus 1, the base station correctly solved a SACCH message, the counter plus two (no more than Link_fail defined counter value). When the base station can not correctly decode a SACCH message, HDPC in the counter (the maximum value defined by the link_fail) minus 1, the base station correctly solved a SACCH message, the counter plus two (no more than Link_fail defined counter value). When the counter is zero, the base station to stop firing downlink SACCH, while start rr_t3109 timer (rr_t3109> T100). When the counter is zero, the base station to stop firing downlink SACCH, while start rr_t3109 timer (rr_t3109> T100). T100 timeout when the mobile station, mobile station back to idle mode, dropped calls occur. T100 timeout when the mobile station, mobile station back to idle mode, dropped calls occur. When the base station until the rr_t3109 timer to the release of wireless channel. When the base station until the rr_t3109 timer to the release of wireless channel. BSC also need to send a Clear request to the MSC message. BSC also need to send a Clear request to the MSC message.
Uplink and downlink failure of any party, will stop sending to each other SACCH. Uplink and downlink failure of any party, will stop sending to each other SACCH. Radio resource to start the process of releasing the other party. Radio resource to start the process of releasing the other party. TCH occurred in a link_fail, statistics for the first RF_LOSSES_TCH. TCH occurred in a link_fail, statistics for the first RF_LOSSES_TCH. Occurred in the SDCCH a link_fail, statistics for the first RF_LOSS_SD. Occurred in the SDCCH a link_fail, statistics for the first RF_LOSS_SD. In theory, the timer can shorten rr_t3109 early release of radio resources (to ensure rr_t3109> T100), to prepare for distribution to other mobile stations, can slightly reduce channel congestion. In theory, the timer can shorten rr_t3109 early release of radio resources (to ensure rr_t3109> T100), to prepare for distribution to other mobile stations, can slightly reduce channel congestion. Optimization process is actually not modified at all. Optimization process is actually not modified at all.
Parameters of wireless links Ultra (radio_link_timeout) will affect when the size of the drop call rate and the wireless network resource utilization. Parameters of wireless links Ultra (radio_link_timeout) will affect when the size of the drop call rate and the wireless network resource utilization. If set too small, it is easy to start handoff before, T100 time-out, resulting in dropped calls caused by wireless link failure. If set too small, it is easy to start handoff before, T100 time-out, resulting in dropped calls caused by wireless link failure. If you set too large, then the call quality is poor, the system a long time to release the radio resources to reduce resource utilization. If you set too large, then the call quality is poor, the system a long time to release the radio resources to reduce resource utilization.
When the network switch to send the mobile station received access message, physical channel to be essential to achieve synchronization status. When the network switch to send the mobile station received access message, physical channel to be essential to achieve synchronization status. As long as the communication channel quality can be guaranteed to receive the mobile station should be able to correct physical information, and to send a layer 2 network structure of the frame. As long as the communication channel quality can be guaranteed to receive the mobile station should be able to correct physical information, and to send a layer 2 network structure of the frame. If the physical information sent to the mobile station can not receive after the issue of layer 2, typically, poor quality physical channel can not carry out normal communication, the appropriate increase in the number of physical information re-issued, so that the quality of the physical channel network in the upturn issued by the mobile station receives the layer 2 frames to complete the switching process, thus avoiding unnecessary dropped calls. If the physical information sent to the mobile station can not receive after the issue of layer 2, typically, poor quality physical channel can not normal communication, the appropriate increase in the number of physical information re-issued to the network at the physical change for the better channel quality to the mobile station when the received level 2 issued to complete the switching process, thus avoiding unnecessary dropped calls.
Handover access failure due to dropped calls of the main reasons: Handover access failure due to dropped calls of the main reasons:
? lack of signal strength coverage unstable, MS can not be properly received. ? lack of signal strength coverage unstable, MS can not be properly received. This mostly occurs in the course of an emergency switch. This mostly occurs in the course of an emergency switch. Cause MS can not normally receive PHYS INFO message. Cause MS can not normally receive PHYS INFO message.
Wrong switch, as the services may exist around the two communities with the BCCH of the cell, resulting in the activation of another system error plot of the TCH, MS PHYS INFO message can not be correctly received. Wrong switch, as the services may exist around the two communities with the BCCH of the cell, resulting in the activation of another system error plot of the TCH, MS PHYS INFO message can not be correctly received.
At present most of the Ericsson system, network, T3105 and NY1 are using the system default settings, specific to TIMER3105 = 4 (40 ms), NOOFPHYSINFOMSG = 35 (35 times). At present most of the Ericsson system, network, T3105 and NY1 are using the system default settings, specific to TIMER3105 = 4 (40 ms), NOOFPHYSINFOMSG = 35 (35 times). For some of the more serious interference with the network (such as China Unicom Network GSM900 1 × 1), 40 ms latency and 35 times the weight obviously not the right hair, the light of experience appropriate to improve T3105 and NY1 (NOOFPHYSINFOMSG), can effectively reduce the switching in dropped calls occurred. For some of the more serious interference with the network (such as China Unicom Network GSM900 1 × 1), 40 ms latency and 35 times the weight obviously not the right hair, the light of experience appropriate to improve T3105 and NY1 (NOOFPHYSINFOMSG), can effectively reduce the switching in dropped calls occurred.
The direct cause of dropped calls, there are two: 1, RF loss. The direct cause of dropped calls, there are two: 1, RF loss. 2, switch dropped calls (Note: The switch failure does not mean dropped calls, switching failure> switch dropped calls). 2, switch dropped calls (Note: The switch failure does not mean dropped calls, switching failure> switch dropped calls). The following analysis of these two cases. The following analysis of these two cases.
(1) RF loss (1) RF loss
A. A. Failure specification defines the downlink, mobile Taichung timer S (T100), in the beginning of the call the mobile station is assigned an initial value, that is, the wireless link timeout (radio_link_timeout). Failure specification defines the downlink, mobile Taichung timer S (T100), in the beginning of the call the mobile station is assigned an initial value, that is, the wireless link timeout (radio_link_timeout). This value is broadcast in the BCCH. This value is broadcast in the BCCH. Whenever the mobile station can not correctly decode a SACCH message (4 SACCH BLOCK) time, S minus 1. Whenever the mobile station can not correctly decode a SACCH message (4 SACCH BLOCK) time, S minus 1. Whenever the mobile station correctly decode a SACCH message, S plus 2. Whenever the mobile station correctly decode a SACCH message, S plus 2. However, the definition of S does not exceed radio_link_timeout initial. However, the definition of S does not exceed radio_link_timeout initial. When the S count is zero, the mobile station to give up radio resource connection, enter the idle mode. When the S count is zero, the mobile station to give up radio resource connection, enter the idle mode. Occur once dropped calls. Occur once dropped calls.
B. B. Uplink uplink failure failure
System failed to monitor the parameters of the uplink is link_fail. System failed to monitor the parameters of the uplink is link_fail. When the base station can not correctly decode a SACCH message, HDPC in the counter (the maximum value defined by the link_fail) minus 1, the base station correctly solved a SACCH message, the counter plus two (no more than Link_fail defined counter value). When the base station can not correctly decode a SACCH message, HDPC in the counter (the maximum value defined by the link_fail) minus 1, the base station correctly solved a SACCH message, the counter plus two (no more than Link_fail defined counter value). When the counter is zero, the base station to stop firing downlink SACCH, while start rr_t3109 timer (rr_t3109> T100). When the counter is zero, the base station to stop firing downlink SACCH, while start rr_t3109 timer (rr_t3109> T100). T100 timeout when the mobile station, mobile station back to idle mode, dropped calls occur. T100 timeout when the mobile station, mobile station back to idle mode, dropped calls occur. When the base station until the rr_t3109 timer to the release of wireless channel. When the base station until the rr_t3109 timer to the release of wireless channel. BSC also need to send a Clear request to the MSC message. BSC also need to send a Clear request to the MSC message.
Uplink and downlink failure of any party, will stop sending to each other SACCH. Uplink and downlink failure of any party, will stop sending to each other SACCH. Radio resource to start the process of releasing the other party. Radio resource to start the process of releasing the other party. TCH occurred in a link_fail, statistics for the first RF_LOSSES_TCH. TCH occurred in a link_fail, statistics for the first RF_LOSSES_TCH. Occurred in the SDCCH a link_fail, statistics for the first RF_LOSS_SD. Occurred in the SDCCH a link_fail, statistics for the first RF_LOSS_SD. In theory, the timer can shorten rr_t3109 early release of radio resources (to ensure rr_t3109> T100), to prepare for distribution to other mobile stations, can slightly reduce channel congestion. In theory, the timer can shorten rr_t3109 early release of radio resources (to ensure rr_t3109> T100), to prepare for distribution to other mobile stations, can slightly reduce channel congestion. Optimization process is actually not modified at all. Optimization process is actually not modified at all.
Parameters of wireless links Ultra (radio_link_timeout) will affect when the size of the drop call rate and the wireless network resource utilization. Parameters of wireless links Ultra (radio_link_timeout) will affect when the size of the drop call rate and the wireless network resource utilization. If set too small, it is easy to start handoff before, T100 time-out, resulting in dropped calls caused by wireless link failure. If set too small, it is easy to start handoff before, T100 time-out, resulting in dropped calls caused by wireless link failure. If you set too large, then the call quality is poor, the system a long time to release the radio resources to reduce resource utilization. If you set too large, then the call quality is poor, the system a long time to release the radio resources to reduce resource utilization.
What is E1 and T1
What is E1 and T1
The PDH (plesiochronous Digital Hierarchy) has 2 primary communication systems as its foundation.
These are,
T1 system based on 1544kbit/s that is recommended by ANSI &
E1 system based on 2048kbit/s that is recommended by ITU-T.
Common Characteristics :-
Both are having Same Sampling Frequency i.e. 8kHz.
In both (E1 & T1) Number of samples/telephone signal = 8000/sec.
In both (E1 & T1) Length of PCM Frame = 1/8000s = 125µs.
In both (E1 & T1) Number of Bits in each code word = 8.
In both (E1 & T1) Telephone Channel Bit Rate = 8000/s x 8 Bit = 64 kbit/s.
Differing Characteristics :-
In E1 Encoding/Decoding is followed by A-Law while in T1 Encoding/Decoding is followed by µ-Law.
In E1 - 13 Number of Segments in Characteristics while in T1 - 15Number of Segments in Characteristics.
In E1 - 32 Number of Timeslots / PCM Frame while in T1 - 24 Number of Timeslots / PCM Frame.
In E1 - 8 x 32 = 256 number of bits / PCM Frame while in T1 - 8 x 24 + 1* = 193 number of bits / PCM Frame. (* Signifies an additional bit).
In E1 - (125µs x 8)/256 = approx 3.9µs is the length of an 8-bit Timeslot while in T1 - (125µs x 8)/193 = approx 5.2µs is the length of an 8-bit Timeslot.
In E1 - 8000/s x 256 bits = 2048kbit/s is the Bit Rate of Time-Division Multiplexed Signal while in T1 - 8000/s x 193 bits = 1544kbit/s is the Bit Rate of Time-Division Multiplexed Signal.
What is Optimum Value of T200?
What is Optimum Value of T200?
we like to know the optimum value for T200 on LAPDm. All vendors have different default values (Siemens 145 ms, Nokia 220 ms, Satellite Abis 400 ms etc.) for this timer - but which value is the best to reduce SDCCH drops and to keep the retransmissions at an acceptable level ?
Example: SDCCH/8
During a 51er multiframe the SDCCH/8 occupies four consecutive TDMA frames (four bursts are sent). Than the MS / BTS has to wait for the next 51er multiframe (i.e. 235 ms) before the next Layer 2 frame could be sent. 145 ms / 220 ms are shorter than the 51er multiframe (235 ms) so in case of an missing acknowledgement this is always a T200 expiry. The SDCCH drop will occur if T200 expired N200+1 times. If the T200 is increased (for example to 500 ms) we have two 51er multiframe to get the acknowledgement and the SDCCH drops are reduced.
The Qos Stats show a clear & strong corelation between the KPI and the parameter T200. That's amazing !
Regarding the Ack from the BTS, I'm not sure (and I'm tired to look in the 3GPP specs :) ). Take the subchannel "0" from the SDCCH ts.
in DL : the BTS sends SDCCH/0 on burst 0, 1, 2, 3 and the SACCH/0 on burst 32, 33, 34, 35
in UL : th MS sends SDCCH/0 on burst 15, 16, 17, 18
and the SACCH/0 on 47, 48, 49, 50
And I ***believe*** that the Lapdm acknowledgments can be sent on either the SACCH or the SDCCH, since both of them are sent over the same LapDm link. I'm not sure at all about this though, but it sounds logical.
The value of the SDCCH Drop due to Radio failures (in ALU) is usually around 1% in a fairly good network. The SDCCH Drop due to Radio Failures is a counter that encompasses both the Radio Link Timeout and the "T200*N200+1 times" failures.
I am not able to test your changes because I am not working on a live network (i am a gsm trainer, living in a world of theory...)
T200 = 220ms for sDCCH SAPI0
= 450ms for SDCCH SAPI3
= 900ms for SACCH associated to SDCCH
we like to know the optimum value for T200 on LAPDm. All vendors have different default values (Siemens 145 ms, Nokia 220 ms, Satellite Abis 400 ms etc.) for this timer - but which value is the best to reduce SDCCH drops and to keep the retransmissions at an acceptable level ?
Example: SDCCH/8
During a 51er multiframe the SDCCH/8 occupies four consecutive TDMA frames (four bursts are sent). Than the MS / BTS has to wait for the next 51er multiframe (i.e. 235 ms) before the next Layer 2 frame could be sent. 145 ms / 220 ms are shorter than the 51er multiframe (235 ms) so in case of an missing acknowledgement this is always a T200 expiry. The SDCCH drop will occur if T200 expired N200+1 times. If the T200 is increased (for example to 500 ms) we have two 51er multiframe to get the acknowledgement and the SDCCH drops are reduced.
The Qos Stats show a clear & strong corelation between the KPI and the parameter T200. That's amazing !
Regarding the Ack from the BTS, I'm not sure (and I'm tired to look in the 3GPP specs :) ). Take the subchannel "0" from the SDCCH ts.
in DL : the BTS sends SDCCH/0 on burst 0, 1, 2, 3 and the SACCH/0 on burst 32, 33, 34, 35
in UL : th MS sends SDCCH/0 on burst 15, 16, 17, 18
and the SACCH/0 on 47, 48, 49, 50
And I ***believe*** that the Lapdm acknowledgments can be sent on either the SACCH or the SDCCH, since both of them are sent over the same LapDm link. I'm not sure at all about this though, but it sounds logical.
The value of the SDCCH Drop due to Radio failures (in ALU) is usually around 1% in a fairly good network. The SDCCH Drop due to Radio Failures is a counter that encompasses both the Radio Link Timeout and the "T200*N200+1 times" failures.
I am not able to test your changes because I am not working on a live network (i am a gsm trainer, living in a world of theory...)
T200 = 220ms for sDCCH SAPI0
= 450ms for SDCCH SAPI3
= 900ms for SACCH associated to SDCCH
What is difference between congestion and Blocking?
Congestion = time when all resources are occupied (no free TCH available)
Blocking = rejected (blocked) attempts over all attempts in %.
Also there is different formulas for TCH blocking. For example in subscriber perceived TCH Blocking all successful directed retries to another cell are removed from the nominator.
Answer2:
Blocking dives you the non served calls
congestion gives the time when no resource are available (it is possible that nobody needs them so no blocks)
there is a possiblity to have high blocking and low congestion - this means that you have a peak of the attempts.
Blocking = rejected (blocked) attempts over all attempts in %.
Also there is different formulas for TCH blocking. For example in subscriber perceived TCH Blocking all successful directed retries to another cell are removed from the nominator.
Answer2:
Blocking dives you the non served calls
congestion gives the time when no resource are available (it is possible that nobody needs them so no blocks)
there is a possiblity to have high blocking and low congestion - this means that you have a peak of the attempts.
what is TCH Blocking and Drop?
TCH call Blocking , it present how many subscriber asks for TCH channel and network reply with no available resource.
so it present how many subscriber request TCH channel to reject this request
TCH call drop
after subscriber get TCH and start converstion
during it the call is dropped for some reasons not related to the subscribers .
so it present how many subscriber request TCH channel to reject this request
TCH call drop
after subscriber get TCH and start converstion
during it the call is dropped for some reasons not related to the subscribers .
Handover failure due to protocol error
verify the ciphering algo used in both External Cells.this via DT.In case of ciphering issue, handover from one side to other should be happening. i.e. the side using higher ciphering algo will be able to transfer the call to cell with lower ciphering algo.
KPI Introduction
1. CSSR (CALL SETUP SUCCESS RATE)
Definition: Rate of calls going until TCH successful assignment
2. SCR (SUCCESSFULL CALL RATE)
Definition: Rate of calls going until normal release that is not interrupted by SDCCH DROP, neither by assignment failures, and neither by CALL DROP.
3. CALL DROP RATE (CDR)
Definition: Rate of all losses of TCH connections during a call in relation to the number of successful Call Setups
4. HOSR (HAND OVER SUCCESS RATE)
Definition: Successful internal and external outgoing handovers of total number of internal and external outgoing handover attempts
5. PSR (PAGING SUCCESS RATE)
Definition: Rate of successful paging attempts of total number of paging attempts.The formula is based on NSS point of view (based on MSC or LAC)
6. LOCATION UPDATE SUCCESS RATE
Definition: Successful location update
attempts of total number of location update attempts. The formula is based on NSS point of view.
7. SDCCH BLOCK RATE
Definition: SDCCH congestion of total number of SDCCH seizure attempts
8. SDCCH DROP RATE
Definition: Dropped SDCCH connections of total number of SDCCH connections without TCH congestion.
9. TCH ASSIGNMENT BLOCK RATE
Definition: Rate of TCH unsuccessful seizures during assignment procedure due to congestion
10. TCH Assignment Failure Rate (exclude blocking)
Definition: Rate of RTCH seizure failed (system + radio) during normal assignment procedure over the total amount of RTCH request for normal assignment procedure
11. EMD (Erlang Minute per Drop)
Definition: Total of Erlang minutes (TCH occupation) in one period measurement per drop call (after TCH Assignment).
12. TCH Availability
Definition: Available TCH of total number of defined TCH
13. RACH Success Rate
Definition : Rate of Successful RACH over the total number of channel required message received
Definition: Rate of calls going until TCH successful assignment
2. SCR (SUCCESSFULL CALL RATE)
Definition: Rate of calls going until normal release that is not interrupted by SDCCH DROP, neither by assignment failures, and neither by CALL DROP.
3. CALL DROP RATE (CDR)
Definition: Rate of all losses of TCH connections during a call in relation to the number of successful Call Setups
4. HOSR (HAND OVER SUCCESS RATE)
Definition: Successful internal and external outgoing handovers of total number of internal and external outgoing handover attempts
5. PSR (PAGING SUCCESS RATE)
Definition: Rate of successful paging attempts of total number of paging attempts.The formula is based on NSS point of view (based on MSC or LAC)
6. LOCATION UPDATE SUCCESS RATE
Definition: Successful location update
attempts of total number of location update attempts. The formula is based on NSS point of view.
7. SDCCH BLOCK RATE
Definition: SDCCH congestion of total number of SDCCH seizure attempts
8. SDCCH DROP RATE
Definition: Dropped SDCCH connections of total number of SDCCH connections without TCH congestion.
9. TCH ASSIGNMENT BLOCK RATE
Definition: Rate of TCH unsuccessful seizures during assignment procedure due to congestion
10. TCH Assignment Failure Rate (exclude blocking)
Definition: Rate of RTCH seizure failed (system + radio) during normal assignment procedure over the total amount of RTCH request for normal assignment procedure
11. EMD (Erlang Minute per Drop)
Definition: Total of Erlang minutes (TCH occupation) in one period measurement per drop call (after TCH Assignment).
12. TCH Availability
Definition: Available TCH of total number of defined TCH
13. RACH Success Rate
Definition : Rate of Successful RACH over the total number of channel required message received
Wednesday, May 12, 2010
Welcome telecom professionals
Welcome all the telecom professionals to my blog.
Please share the telecom releated articles.
Please share the telecom releated articles.
Subscribe to:
Posts (Atom)