Value Added Service (VAS) through mobile internet servicewhich involves data service equipment such as download contents, mobile shopping, subscription service and service based on BREW platform, it is very though to identify partial problem such as error “network busy” during certainty period e.g. busy hour rather than we notice that the service goes down. While telecommunication companies experience this partial problem for example partial problem on download contents on BREW platform, the action they will do to identify root cause of problem and fix it soon are;

1. Identifying the pattern of problem through the mobile phone/ handset

Collecting the pattern of errors while subscriber experience such as whether subscriber completely getting a problem while accessing the download content, mobile shopping and subscription services or they are getting problem while accessing to particular application and what the message will appear on the mobile phone/handset while problem is coming

2. Identifying the Radio Frequency (RF) capacity

Network busy is the common issue on wireless/mobile internet service including Value Added Service (VAS). If the location which covers the service is having good quality of signal but the service is still getting problem, it means that RF capacity is not contributing to this partial problem. Confirmation that the capacity of signal is sufficient to carry out the traffic including VAS service is needed to go to the further investigation

3. Tracing the session from the central process of data service such as Public Data Serving Node (PDSN)

All sessions to access the entire of application on VAS services will go through PDSN node. By tracing a particular session which experience error “network busy”, we can identify whether the request from subscriber already sent to the application server and responded back to the subscriber or not

4. Identifying packet data received at data communication equipment, application server, Domain Name Server (DNS) and charging gateway

By tracing to the application systems related to VAS service we can identify packet data which come and go the each application service and analyze whether each element already receive and response the request from subscriber or not. This section will identify which part of network element that did not run proper while a request from subscriber is coming

Incoming search terms for the article:

• how value added services VAS works (1)
• identify the value added services (1)
• identify value add (1)
• identifying the problem (1)
• problem of value added (1)
• Tentang usb modem internet aha (1)
• tips and issues for value added services in Telecoms (1)
• value added service of Verizon Wireless (1)

Late response from BREW server could be caused by many things such as network topology from user (BREW client) to BREW server, the capacity of BREW server and response time from the network element on mobile internet service between them such as charging gateway etc. Once it is coming, telecommunication companies should identify this case and resolve immediately. The first thing they need to do is identify which network element that contributes to this late response. To get this information, telecommunication engineer have to do some effort below;

1.      Dump the traffic from the network element which involved to the BREW application such as BREW server, charging gateway and Domain Name Server (DSN) server

They can use tcpdump command if they are using Linux operating system to identify whether request is arriving to those network elements and responded back by them or not. It is also can be done if the network element such as charging gateway on the mobile internet service has the tool to capture the full packet come and go through it.

2.      Snoop the traffic from the data communication network such as router etc

Snoop has the same goal that is the identify whether the traffic come and go through the data com network such as router

3.      Tracing from the handset it self

Each handset/mobile phone vendor usually has a tool to get information about any packet come and go through the mobile phone/handset

Actually the critical issue while late response happened to the application service based on BREW platform is contributing from the network topology itself where BREW application implemented on the mobile internet service . This is how the traffic will be routed from the mobile phone/handset to the BREW server and vice versa. The best network topology to run the BREW service is efficient network where it is required less time to deliver the traffic from source and destination address

Incoming search terms for the article:

• BREW time from application start (5)
• apa itu brew (3)
• apa itu modem aha (1)
• brew appli (1)
• brew application (1)
• brew client (1)
• brew itu apa ? (1)
• broadband destination adress problem (1)
• pr3 bre problem (1)

Although BREW services need a less RF capacity but sometime session will also retrieve error message that could be from any network element. BREW client will generate error such as “network busy” while they are trying to access the BREW application. This error could be caused by many reasons such as lack of RF capacity; the server was down etc. this error should be identified and get a resolution immediately to reduce many complaints from subscribers

There are many ways to ensure what the root cause of this problem and how to fix it. Analyzing to all of network elements is needed as one network element connect and support to another one. One of the methods to identify the root cause of problem and fix it is by tracing the session from each network elements. BREW services on mobile internet service are running on application layer and once we ensure that no issue on the application, tracing the entire of session to produce the complete logs and analyze it is very useful.

The network elements which need to be traced to get a useful data are;

1. Base Station Controller (BSC)
2. Mobile Switching Controller (MSC)
3. Public Data Service Node (PDSN)
4. BREW server

By tracing on the BSC we will notice if user already sent the request to PDSN and get the response through A10/11 protocol. We can say that no issue found on the BTS, BSC and MSC once we confirm that the connection between BSC to PDSN is established. We can ensure it once the request from BSC was responded by PDSN. Tracing log from the PDSN will give more information whether the session is established or not and whether user retrieves the application from BREW server or not. Here also we can find why the session was disconnected and who did it. PDSN is the central processing of wireless or mobile internet service including BREW services (download content). The entire of data service process is happening in this network element. Therefore, information about the failed session we can find here; who is not responding and why they are not.

We also can do tracing the session from the BREW server to identify if the request from subscriber arrive to the server or not and if server gives a response to this request. Once we have complete information from each network elements then we can take a resolution to avoid the same case happen in the future