Authors: Nihar Ranjan
Certificate: View Certificate
It is known that different PC suites exist for different mobile companies. We propose a system in which we provide a common interface for different mobiles. Universal PC suite helps to us connect all mobile devices in a common interface which provides the same functionality as the normal PC suite. Different mobile devices can be connected in Universal PC suite and user can access their contacts, messages, phone and memory with the PC suite interface. This is done with the help of AT Commands. More than 90% of the phone modems support AT Commands and is detected by our Desktop with the help of HyperTerminal.
PC Suite is a software package used to establish an interface between mobile devices and computers that run on Microsoft Windows operating system. Today there are different mobile device provider, providing different range and models but there is no such common interface available which provides the same functionality. This software package is same as a (normal) pc suite but can be used on any type of phone modem, independent of: the manufacturer and the phone model. This innovative idea of pc suite that is universal to all modem is proposed for the first time ever. According to our survey PC suite is the most widely used software available in the market. PC Suite is a software package used to establish an interface between mobile devices and computers. Today there are different mobile device provider, providing different range and models. Each mobile device provider has their own PC suite software in which only the mobile device manufactured by that company can be used to make calls and send messages using computers. But there is no such common interface available which provides the same functionality.
In this paper, we propose Communication of Different Phone Modems into a Single PC Suite using AT Commands. This paper is aimed at mobile phone users who carry more than one mobile and can retrieve data from mobile phones, irrespective of the phone modem used. This paper can find varied application in business and day to day life.
The application works on the principle of AT Commands. AT Commands are used by an external device to communicate with the PC using HyperTerminal. More than 90% of the mobile phones support the concept of AT Commands. The mobile device is connected to the PC with the help of an USB. USB is the communication port between the phone modem
and the pc suite. USB helps to recognise the type of external device connected to the PC.
The main objectives implemented through this paper are as follows:
So using this facility of connecting to computer as a modem, we will be retrieving useful data from the modem. This data is used in our PC Suite. Using USB cable we will be communicating the phone modem and sending instructions and commands to the modem. The modem in response will reply back with string that will be used to decode the output and hence make our PC Suite
The normal PC Suite functions implemented using this paper is as follows:
a. SMS - This feature allows you to send text messages to desired phone numbers using the connected phone modem. This feature allows you to connect to internet using the connected phone modem.
b. Call - This feature allows you to create a voice call using the connected phone modem.
c. Internet - CONTACTS - This feature allows you to read contacts from the connected phone modem.
d. Battery - This feature allows you to check battery level of the connected phone modem.
e. Phone Info - This feature allows you to know information about the connected phone modem.
f. Signal Strength - This feature allows you to check signal strength of the connected phone modem.
The extra features implemented which are not available in our todays pc suites are as follows:
A Terminal is a device which is capable of communicating over a line. Examples of terminals are telephones, fax machines and network devices – printers and workstations. The mobile data terminal (MDT) is used in the field of telematics. HyperTerminal has capabilities beyond making connections to other computers. It can, for example, transfer large files from a computer onto your portable computer using a serial port rather than requiring you to set up your portable computer on a network. It can help debug source code from a remote terminal. It can also communicate with many older, character-based computers.
HyperTerminal records the messages passed to and from the computer or service on the other end of your connection. It can therefore serve as a valuable troubleshooting tool when setting up and using your modem. To make sure that your modem is connected properly or to view your modem's settings, you can send commands through HyperTerminal and check the results. HyperTerminal also has scroll functionality that enables you to view received text that has scrolled off the screen. HyperTerminal is the principle of user input at any time be sent to the serial port (using the TCP protocol is sent to the Ethernet port, serial port here only that, but does not display the input and it shows the character received from the serial port, so embedded in systems should be appropriate procedures to accomplish is: 1, start your own information, process information unsolicited to a host running HyperTerminal, 2, will receive the character back to the host and sends the characters to be displayed ( If the command response until the host.
B. AT Commands
AT Commands are used to control modems to do their specified functions. Cellular phones are not much different from the old dial-up modems that are still found in many computers. The Hayes command set (also known as AT Commands) is a specific command-language originally developed for the Hayes Smartmodem 300 in 1981. The command set consists of a series of short text strings which combine together to produce complete commands for operations such as dialling, hanging up and changing the parameters of the connection.
The Hayes command set includes commands for various phone-line manipulations, dialling and hanging-up for instance. It also includes various controls to set up the modem, including a set of register commands which allowed the user to directly set the various memory locations in the original Hayes modem. The command set was copied largely verbatim, including the meaning of the registers, by almost all early 300 baud modem manufacturers, of which there were quite a few. The expansion to 1200 and 2400 baud required the addition of a small set of new commands, some of them prefixed with an ampersand ("&") to denote those dedicated to new functionality. Hayes themselves were forced to quickly introduce a 2400 baud model shortly after their 1200, and the command sets were identical as a time-saving method. Essentially by accident, this allowed users of existing 1200 baud modems to use the new Hayes 2400 models without changing their software. This re-inforced the use of the Hayes versions of these commands. Years later, the TIA/EIA raised the 2400-baud command set into a formal standard with the title Data Transmission Systems and Equipment - Serial Asynchronous Automatic Dialling and Control, TIA/EIA-602.
Connecting ports program will enquire about the available ports from the system and will feed it into an array. Then the array will give you option to choose the available ports to connect it. User can select the port and then proceed further. The ports will be checked and responding ports list will only be displayed on the modems list.
Program will query about the manufacturers identity information based on the identity of the manufacturer the program will switch to a common mode that will retrieve maximum AT commands from the modem. It will display every possible information that can be displayed .After accessing information from the AT commands it will get to a custom interface based on the specific phone manufacturer. Hence you can even access more features in in one route. Variance of most of the congestion detection parameters is proportionate to traffic pattern. This means that with increasing transmission rate, variance of them are increased and reducing rate decreases their variance. The only parameter that does not show this behavior is inter-arrival time of packets. This parameter is useful when inter transmission time of packets are equal and in such a condition it is recognized that if inter reception of them changed we infer that there is a congestion in the path. But source node in video traffics transmit packet in different intervals (packets belonging to different frame types) and so sink cannot determine whether the interval between receiving packets are due to congestion or for another reason. So this parameter is not convenient for our video network.
PC Suite itself is an application used by the mobile phone users. Nowadays people carry more than one phone for communication.
This application comes in handy as they can connect many different phones and retrieve information according to their use.
It is technically feasible as the application can be installed in any Windows Desktop PC.
A. Speed of congestion detection
Quick congestion control depends on two factors: quick congestion detection and suitable rate adjustment. One important criteria comparison among congestion detection methods is that which method can detect congestion more instantaneously. One of the most useful criteria is that which parameter has more change in case of network congestion. For example comparing two parameters of delay and jitter we have the following averages for them.
In these formulas d is delay of current packet and ? is weight that is assigned to delay in weighted average delay. Davg is average delay of packets of a flow. In above equation for computing average jitter instead of using absolute value of jitter, the unchanged jitter is used. This is because when congestion is terminated and delay is reduced using absolute jitter causes that average jitter is increased and a misdetection of congestion is produced. If we do not use absolute value when congestion is passed average jitter is decreased.
In the above equations the more ? be closed to 1 means that we gave a more weight to previous average delay. So average delay gained a slower pace than change of delay and so reaction to congestion is slow. Advantage of this behavior is that when delay of some packets is not because of congestion situation and is transient, this method does not have congestion misdetection. The more ? is close to 0, it means that more weight is used for delay of current packets. So a small increase in delay of current packets increases the average. In this case congestion is detected more rapidly but in some cases there is a misdetection of a nonexistent congestion. We know that by the advent of congestion in network, queue length in intermediate nodes is increased and as a result delay of packets is increased. Having a scrutiny in above equations we come to the conclusion that delay of each packet has a direct effect on average delay. But difference of delay of each packet versus average delay makes jitter. So by increase of delay, average of delay grows quicker than average of jitter and therefore congestion is detected and controlled quicker consequently. The other problem of average jitter is that when congestion frequently occurs in network and network is often in congestion state, average jitter is reduced instead of increasing or remaining constant and as a result congestion is not detected. On the other hand average delay in these situations always is above its threshold and always detects the congestion.
To sum up, average jitter is not a suitable parameter for video traffic congestion detection. In the following we simulate a congested network to verify the discussion and select the best congestion detection parameter in accuracy and quickness. The parameter that responds quicker to congestion is the most convenient. Remaining congestion detection parameters are: average delay, average service time, queue length of nodes. Some examples of AT commands along with its parameters
We use NS2 and Evalvi tool in our simulation. Simulation parameters are shown in TABLE V. Five nodes are considered in our simulation arrangement of which are depicted in Figure 1. Node 5 is sink. Initially consider that node 1 sends packets of Foreman video file with MPEG format. In Figure 2 we have shown change process of delay parameter for node 5. Average service time and queue length for node 3 is also shown in Figures 3 and 4. We assume that our network can tolerate one single burst and applications would not be affected in such a burst. But our network will not be respondent if two or more flows simultaneously go to a burst. So packets will be late in sink or will be discarded. Thus congestion will occur and we must detect it. We want to use the parameter that detects it quicker and with more probability.
For evaluating threshold value we use the following method. Maximum amount of that parameter in case of one single burst of a flow will be our threshold. Now with increasing simultaneous flows we investigate that which parameter and when violates the threshold. In previous figures we conceive that maximum amount of average delay for a flow is 64 milliseconds and maximum queue length for the same number of flows is 6 and maximum average service time is 16 milliseconds. We consider these values as our network threshold.
We start the simulation from scratch. This time both node 1 and 2 are sending simultaneously and because they use the same coding format they go burst together. Average delay of node 5, average service time and queue length for node 4 is depicted in figures 5, 6 and 7. In these figures we see the change in value of parameters with the increase of a simultaneous flows and occurrence of congestion. We observe that average delay only in a single congestion case does not violate its threshold. But queue length passes its threshold only 3 times and this threshold passing for service time is only 5 times. Both service time and queue length have similar change. But delay in occurrence of congestion have further change and so better detects congestion in terms of both speed and accuracy.
According to what preceded in this paper we conclude that average delay is the best parameter for congestion detection for video and other multimedia traffic in WMSNs. Advantages of using this parameter are as follows: It has lower cost for congestion detection and besides has a direct effect on quality of received video. Delay parameter not only uses local information but also it considers the whole network status. Furthermore it is accurate in congestion detection and it quickly detects congestion in network. The other advantage is that it can be used in either sink or in intermediate nodes. This leads to more flexibility in usage. When quick congestion detection is aimed we may use intermediate nodes to detect and control congestion and if reducing intermediate nodes overhead is favorable we can set sink in charge. One of the disadvantages of delay parameter is the overhead of synchronization between nodes. We did not consider this synchronization because this is not a major issue. Delay can be simulated with some heuristics and it can become independent of synchronization. So this is left for future work on the problem.
 E. Gurses, O.B. Akan, \"Multimedia communication in wireless sensor networks,\" Annales des Telecommunications/Annalsof Telecommunications 60 (2005) 799–827.  I.F. Akyildiz, T. Melodia, K. Chowdhury, \"A survey on wireless multimedia sensor networks,\" Computer Networks 51 (2007) 921–960.  C. Wang, K. Sohraby, \"A Survey of Transport Protocols for Wireless Sensor Networks,\" IEEE Network 20 (2006) 34-40.  X. Zhu, B. Girod, \"Distributed rate allocation for multistream video transmission over ad hoc networks,\" In Proc. of IEEE Intl. Conference on Image Processing (ICIP) 2005 Boston 157-160.  Y. G. Iyer, S. Gandham, S. Venkatesan, \"STCP: A generic transport layer protocol for wireless sensor networks,\" In Proc. International Conference on Computer Communications and Networks (ICCCN) 2005 Houston 449-454.  B. Hull, K. Jamieson, H. Balakrishnan, \"Mitigating congestion in wireless sensor networks ,\" In Proc. of the First International Conference on Embedded Networked Sensor Systems (Sensys) 2004 Baltimore 266-279.  Nihar Ranjan, Midhun C., \" Evolutionary and Incremental Text Document Classifier using Deep Learning\" International Journal of Grid and Distributed Computing Vol. 14, No. 1, pp. 587-595, 2021  Midhun C, Nihar Ranjan., \"A Brief Survey of Machine Learning Algorithms for Text Document Classification on Incremental Database\" TEST Engineering and Management, ISSN: 0193-4120, Volume 83, pp 25246 – 25251, June 2020  Zubair Ghouse, Nihar Ranjan “A Multi-function Robot for Military Application” Imperial Journal of Interdisciplinary Research (IJIR) Vol-3, Issue-3, ISSN: 2454-1362, pp 1785-1788, 2017  Mane, D., Bidwe, R., Zope, B., Ranjan, N. (2022). Traffic Density Classification for Multiclass Vehicles Using Customized Convolutional Neural Network for Smart City. Communication and Intelligent Systems . Lecture Notes in Networks and Systems, vol 461. Springer, Singapore.  R.V. Darekar, Meena Chavan, S. Sharanyaa Ranjan Nihar., A hybrid meta-heuristic ensemble based classification technique speech emotion recognition, Advances in Engineering Software,Volume 180, 2023, 103412,I SSN 0965-9978,  Rajesh Prasad, Nihar Ranjan, et.al., “FCM with Spatial Constraint Multi-Kernel Distance-Based Segmentation and Optimized Deep Learning for Flood Detection”, International Journal of Image and Graphics, World Scientific, June 2023,
Copyright © 2023 Nihar Ranjan. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.