Advanced SIP Series: SIP and 3GPP Operations

Transcription

1 Advanced S Series: S and 3GPP Operations, Award Solutions, Inc Abstract The Session Initiation Protocol has been chosen by the 3GPP for establishing multimedia sessions in UMTS Release 5 (R5) networks. This paper discusses the operations of the UMTS R5 Multimedia Subsystem (IMS) in great detail. The paper discusses where S is used in UMTS IMS and the interaction between the various components of the IMS networks. The changes and enhancements made to the Internet telephony signaling protocols such as S, SDP and Megaco are discussed. The interaction between the IMS and the /legacy wireless networks are outlined to provide the reader a complete view of the IMS operations. Introduction Session Initiation Protocol (S) 1 has been chosen as the signaling protocol for establishing multimedia sessions in UMTS Release 5 (R5) Multimedia Subsystems (IMS). In a previous paper on UMTS IMS 2, we presented the rationale for IMS, the basic architecture of IMS and the services architecture of IMS. We also presented a brief overview of where S is used in UMTS IMS. In this paper, we describe the operations defined in UMTS IMS for establishing multimedia sessions. We discuss interaction between S and other protocols such as the UMTS signaling protocols and the signaling protocols. We start with a high-level overview of all of the operations in IMS. In the subsequent sections, we explain each operation in more detail. We follow the overview with a discussion of the UMTS data bearer setup using UMTS signaling protocols. Next, we discuss the service registration process and rationale behind it. In next few sections we provide an in-depth discussion of how multimedia sessions are setup using the User Equipment () origination and termination operations. In these sections, we explain how S is used and enhanced in the IMS networks. The interaction between the IMS and the /legacy networks is an important issue. The next section addresses this issue and explains how another Internet telephony protocol called Megaco 3 is used. In conclusion, we provide a summary of the paper and areas for further specification in UMTS R5 IMS. A Day in the Life of a IMS The UMTS IMS capable mobile station performs several functions to set up a S session. We shall examine the key steps involved before a UMTS S mobile starts a S session 4. The key steps involved in obtaining access to S services are summarized in Fig. 1. System Acquisition UMTS RAN Data Connection Setup Fig. 1. SGSN PS-CN Intra Operator Backbone S-based IMS procedures IMS P-CSCF, High Level Summary of S in UMTS 1. System acquisition: The first step is to power on the mobile and lock on to the UMTS system. Once the appropriate cell is selected, the UMTS mobile is ready to communicate signaling messages required to establish a data session. In this paper, we will assume that this function has been performed by the mobile and will not be discussed in detail. 2. Data Connection Setup: Once the system has been acquired, the next step is to establish the data connection or pipe to the S and other services. The does not know the address of the Proxy-CSCF at 1

2 this point to perform a S registration. The data connection is completed in a two-step process using Attach and Packet Data Protocol (PDP) Context Activation message sequences. This establishes the path required to carry S related signaling messages to the Proxy-CSCF through the, which is the gateway to the Proxy-CSCF. 3. Therefore, the Attach and the PDP Context Activation are two key steps required to create a data pipe to the Proxy CSCF for S services. The response to the PDP Context Activation message also includes the identity of the Proxy-CSCF for the to use to perform the registration process. Now, let s explore the process of how the UMTS registers with the UMTS S network. 4. Service Registration: Before establishing an Multimedia session, the needs to perform the Service registration operation to let the IMS network know the location of the. This registration is an application or S registration for various S services. The UMTS acts as a S client and sends a S registration message to its home system through the Proxy-CSCF. 5. Session Setup: After a PDP context is activated and Service Registration is finished, the can establish a session. We have discussed the key steps in registering for S services. Let s step through the details of the key steps such as Attach, PDP Context Activation and S registration 5. Data Connection Setup Attach Used to establish Mobility Management contexts at SGSN and PDP Context Activation Used to establish connectivity RNC Node B Fig. 2. UMTS Attach UMTS PLMN Intra PLMN Backbone PDP Context Activation Setting up a pipe through the UMTS packet network After the acquires the system, it needs to setup a data connection in order to use wireless packet data services. The procedures described below exist in Release 99 UMTS. At first, the must "attach" itself to a. Attach The first step in the data connection or creation of the data pipe through the UMTS network is the registration for packet service with the UMTS network. The UMTS sends the Attach message to the Serving GPRS Support Node (SGSN), which includes the s International Mobile Subscriber Identifier (IMSI). The SGSN uses the IMSI to send a request to the s Home Location Register (HLR) for the authentication parameters to help authenticate the subscriber. The HLR provides authentication information to the SGSN, enabling the SGSN to verify the veracity of the subscriber s IMSI. The successful completion of authentication procedure triggers the SGSN to send a location update (which provides the UMTS s IMSI) to the HLR and this triggers the subscriber s profile to be downloaded to the SGSN. This includes information such as the subscribed services, the QoS profile, any static addresses allocated and so on. The SGSN completes the Attach procedure by sending an Attach Complete message to the. A logical association is now established between the and the SGSN and mobility management information or a context now exists between the and the SGSN. With this key step, the location of the mobile is known within the UMTS network. This logical connection is maintained as the moves within the coverage area controlled by that SGSN. Please note that even though the has announced its presence in the UMTS packet network, application packet traffic (for example, S signaling etc.) cannot be transferred at this point. This is the first of two critical steps that an takes toward packet data access and the needs to activate its PDP address (or address) to establish a path to the Internet. PDP Context Activation Once a is attached to an SGSN, it must activate a PDP address (in this case, an address) when it wishes to begin a packet data communication, including S services. Activating a PDP address sets up an association between the s current SGSN and the Gateway GPRS Support Node () that anchors the PDP address. A record is kept regarding 2

3 the associations made between the and SGSN. This record is known as a PDP context. This second and final step is required to establish the data connection or pipe to the Internet. The activation of a PDP context activates an address for the ; the may now exchange traffic using that address. Context activation creates an association for this address between the SGSN and a specific. The UMTS initiates this message and is received by the SGSN. The UMTS sends this message transparently, for example, when the user started a S service on his or her. The PDP Context Activation message contains information such as Access Point Name (APN), which is a logical name referring to a service or a network. In this case, the APN could simply be S service. The PDP Context Activation message also contains additional information such as the address of the, allocated by the wireless provider. All of this information is received by the SGSN, which is crosschecked with the subscriber profile the SGSN received from the HLR. The SGSN proceeds to discover the appropriate using the APN provided. Since the provides an Access Point Name (APN) for establishing the S service, the SGSN chooses the appropriate capable of performing functions required for S services. The SGSN and create special paths or tunnels to transfer packets for this. Once the SGSN- path has been established, the provides the address of the Proxy-CSCF in the PDP context activation accept response message to the. This P-CSCF address is the used by the UMTS to continue with S related activities. The may also send a secondary PDP Context Activations, based on the QoS requirements for each address. The SGSN chooses the appropriate for different contexts and services. The choice of the by the SGSN is independent of the radio resource allocations. A mobile may initiate secondary PDP contexts and may be connected to more than one. is chosen based on the external network and service that the requests, i.e. the APN. In the case of a S service, a PDP context is activated for primarily S signaling initially. This is referred to as Primary PDP Context, which is what we have discussed so far. This PDP context is used to carry all S related signaling including registration and invites etc. The reception of S Invite message may trigger the creation of secondary contexts that are needed for QoS requirements of the service requested. The secondary contexts use the same address as the Primary Context with the exception that it has distinctly different QoS requirements. In this section, we shall discuss the steps leading up to the start of a S service. The initial pipe created for S signaling will be used for registering with the home S server. Once this is completed, secondary contexts may be established for service data transfers. Why Service Registration? As shown in Fig. 2, after it has attached to the network and activated a PDP context, the R5 needs to perform S service registration before it can set up a session. Notify the HSS of current location Authorization by the HSS Send subscriber profile to Visited Network Fig. 3. Authorization HSS The need for service registration The purpose of service registration is as follows: During the course of service registration, the Home Subscriber Server (HSS) for the is notified of the current location of the. The HSS updates the subscriber profile accordingly. Authorization needs to be performed before the user can register. The HSS checks whether the user is allowed to register in the network based on the subscriber profile and operator limitations. The needs a Serving-CSCF in its home network in order to obtain IMS services. During service registration, the home network selects a suitable Serving-CSCF for the and the subscriber profile is sent to the. 3

4 Service Registration This section describes the details of a service registration information flow 6. As an assumption for this scenario, the is located in a visited network and it has completed the Attach and PDP Context Activation operations. It is optional to use the Interrogating-CSCF (), but this scenario assumes that an is used as the entry point to the home network. For scenarios where the is located in the home network, the CSCFs will be located in the home network and the registration information flow will remain the same. checks whether the user is registered already. The HSS indicates whether the user is allowed to register in that visited network according to the user subscription and operator limitations/restrictions (if any). The Cx-Query Response is sent from the HSS to the. 4. The sends the subscriber identity via the UMTS Cx-Select-Pull message to the HSS to request the information related to the required capabilities. This information is needed for selecting a S- CSCF. The HSS sends the required capabilities to the via the Cx-Select- Pull Response message. P-CSCF 1.Register Key: S Message Cx Message Fig. 4. HSS 3. Cx Query & Resp. Authorization Locate 2.Register 4. Cx-Select-pull &Resp. The first four steps of S registrations 1. To start the Service registration process, the sends the S Register message to the Proxy-CSCF. This message includes the subscriber identity and home networks domain name. 2. Upon receipt of the Register message, the P-CSCF examines the home domain name (e.g. ims_sprint.com) to discover the entry point to the home network (i.e. the ) with help from DNS. The proxy sends the Register message to the with the P- CSCF s name, subscriber identity, and visited network contact name. The main job of is to query the HSS and find the location of the Serving CSCF. When the I- CSCF receives the Register message from the proxy, it examines the subscriber identity and the home domain name, and uses DNS to determine address of the HSS. 3. The sends a UMTS proprietary message, Cx-Query 7, to the HSS with the subscriber identity, the home domain name, and the visited domain name. The HSS 6. Cx-put & Resp. Update location Retrieve profile 7. Cx-pull & Resp. Fig. 5. HSS 5. Register P-CSCF S registration continued OK Key: S Message Cx Message 5. The, using the name of the S- CSCF, determines the address of the S- CSCF through a name-address resolution mechanism. The also determines the name of a suitable home network contact point, possibly based on information received from the HSS. The home network contact point may either be the itself, or a suitable in case network configuration hiding is desired. If an is chosen as the home network contact point, it may be distinct from the that appears in this service registration flow. I- CSCF then sends the Register message to the selected. The flow includes the P-CSCF s name, the subscriber s identity, the visited network contact name, and the home network contact point (if needed). The home network contact point will be used by the P-CSCF to forward session initiation signaling to the home network. 4

5 6. The sends a Cx-Put message with the subscriber s identity and the S- CSCF name to the HSS. The HSS stores the name for that subscriber. The HSS sends the Cx-Put Response to the to acknowledge the sending of the Cx-Put. 7. On receipt of the Cx-Put Response message, the sends the Cx-Pull message with the subscriber identity to the HSS in order to be able to download the relevant information from the subscriber profile to the. The stores the P-CSCF s name for use in session termination. The HSS sends Cx-Pull Response with the user information to the. The user information passed from the HSS to the S- CSCF includes one or more names/addresses information, which can be used to access the service control platform(s) while the user is registered at this. The stores the information for the indicated user (This would be equivalent to the VLR data). Security information may also be sent for use within the. 8. In the 200 OK message, the sends the serving network contact information to the, who forwards it to the P-CSCF. The P-CSCF stores the information, and sends the 200 OK message to the. The releases all registration information after sending 200 OK. Originating "Call" setup Now that we have covered the processes of establishing the PDP context and the process of registration, lets move to the establishment of a voice call. We are starting with a voice call because it is simple and intuitive. This process will remain unchanged if this were a multimedia session establishment. Basic Session Setup Procedures In the Multimedia Subsystem specifications, an end-to-end session flow consists of three types of procedures: mobile origination, -to-, and mobile termination. For example, suppose a subscriber is located in their home network. They want to initiate a session to another subscriber who is also in their home network. The two subscribers have subscriptions with the same network operator. This end-to-end session flow may be constructed with the following procedures: Mobile origination, mobile in home network, -to-, origination and termination served by same operator, Mobile termination, mobile in home network. A number of end-to-end session flows may be built from the combinations of origination, serving-toserving, and termination procedures. / BGCF/ (a) (b) (c) UMTS IMS (R5) A R5 can establish sessions with three types of end parties: (a) Another R5 (b) A phone connected to the (c) A multimedia device connected to the network Fig. 6. Session Terminating Endpoints Session Terminating Endpoints An IMS mobile initiates a session by sending a S INVITE message. This message includes the destination address. The destination may be one of the following three types (as shown in Fig. 6): 1. Another IMS mobile: This mobile may or may not be located in the same network as the initiating mobile. The two mobiles can set up a session through their CSCFs. The details of the session setup procedures are discussed in the next section. 2. A phone connected to the : By going through the Media Gateway Control Function () an IMS mobile can set up a session with a traditional phone. 3. A multimedia device connected to the Internet: The destination address may indicate that the destination party is on the 5

6 Internet. Then the session will be set up through the IMS and the network to the destination. A S user agent client or a S server are examples of a multimedia device connected to the Internet. Mobile Origination (Overview) Fig. 7 shows an overview of the mobile origination procedure. This scenario assumes that the mobile is located in a visited network. The sequence is explained below: P-CSCF Destination INVITE SDP Negotiation Resource Reservation Session Setup Confirmation (OK & ACK) Session in Progress Fig. 7. Mobile Origination (Overview) 1. INVITE: The mobile origination procedure is initiated by a S INVITE message sent from the originating mobile. The initial Session Description Protocol (SDP) is included in this message. The message is forwarded from the P-CSCF to the via the, and finally to the destination. 2. SDP negotiation: The two end parties negotiate the media characteristics (e.g. number of media flows, codecs, etc.) for this session and make a decision on the media streams they will support for this session. For the sake of our example, this is assumed to be a basic voice call. 3. Resource Reservation: The network reserves the necessary resources for supporting this session, after the media characteristics for this session have been determined. 4. Session Setup Confirmation: Once resource reservation is completed successfully, the terminating point sends a S 200 OK final response and the originating mobile replies with a S ACK message to confirm the session setup. 5. Session in progress: After the originating mobile receives the 200 OK response, it starts the media flow and the session is in progress. Mobile Origination (Detail) This section presents a detailed description of the process of establishing a session. For this example it is assumed that the mobile is located in a visited network initiates a session. The detailed information flow is described below: 1. The subscriber of the IMS mobile has either dialed digits or used a GUI on the mobile to determine the person that he wants to call. The mobile sends the S INVITE request to the P-CSCF. The INVITE message contains three key pieces of information. The first is the called party in the To header. The second key piece of information is the proposed SDP. This SDP may represent one or more media types for a multi-media session. The last piece of information is the From header that contains the calling party. 2. The P-CSCF remembers (from the registration procedure) the next hop CSCF for this mobile. This next hop is either the S- CSCF in the home network that is serving the visiting mobile, or an within the home network that is performing the configuration hiding function for the home network operator. This scenario assumes that the home network operator wants to keep its network configuration hidden, so the name/address of an in the home network was provided during service registration, and the INVITE request is forwarded through this to the S- CSCF. The P-CSCF will look at the SDP portion of the S message and examine the proposed media types that were proposed by the calling party in establishing a session. The P-CSCF has the option at this point to remove some of the proposed media types based on the types of sessions the visited network wants to support. 3. The validates the service profile, and performs any origination service control 6

7 required for this subscriber. This includes authorization of the requested SDP based on the user's subscription for multi-media services. 4. The also determines the location of the called party based on the information in the To header. As stated before, this could be to another IMS system, to a S capable device (a User Agent Client or a S proxy server) or to a Media Gateway Controller network to go to the. Which network is determined by using DNS to translate the address in the To header to an address. forwards the INVITE request to the destination. It is not clear from the standards if the S- CSCF is a stateless or stateful proxy. It seems logical to assume that it is a stateful proxy since the will support the billing function for the call session. By that same point, the P-CSCF is probably a stateful proxy as well. 5. The called party responds with a provisional response that will include a SDP in the message body. This is the called party s suggestion on the media type. 6. The forwards the SDP information to P-CSCF through. 7. The P-CSCF again looks at the SDP field and removes media types that it does not want to support. The P-CSCF determines the type of resources that are required based on the media type that is requested. / 1. INVITE 4. INVITE 3. Service Control 2. INVITE 7. Authorize QoS Resources P-CSCF 8. The P-CSCF then forwards the SDP information to the originating endpoint (i.e. the mobile). 9. The mobile decides the final set of media streams for this session, and sends the Final SDP to P-CSCF. The P-CSCF will then perform the Policy Control Function and determine the resource requirements. There are a number of options that can happen at this point. The P-CSCF can send the policy information using a protocol like Common Open Policy System (COPS) 8 to the. The P-CSCF could also just store this information in a database. The will send a request to the P-CSCF for permission to setup the requested resources. Please note that the standards have not been completed on the Final SDP message. It is still under development The P-CSCF sends the Final SDP message to the (via the if necessary.) 11. The sends the Final SDP message to the called party. / BGCF/ Destinations 8.SDP 11.Final SDP 9. Final SDP P-CSCF Fig. 9. Mobile Origination (Part 2) 10. Final SDP BGCF/ Destinations 5. SDP Fig. 8. Mobile Origination (Part 1) 6. SDP 12. After determining the final media streams in step #9, the mobile initiates the reservation procedures for the resources needed for this session. The resource reservation takes the form of a secondary PDP context activation or a PDP context modification. At this point the 7

8 mobile will request to take the current bearer path (that was used to send the signaling messaging) to a bearer that will support the media stream and the signaling. The will receive this request and either have the permission to establish (that was sent by the P-CSCF earlier) or the will send a request (via COPS) to the P-CSCF for permission to change the connection. 13. When the resource reservation is completed, the mobile sends the COMET message (to show that the resource reservation has been successful) to the terminating endpoint, via the signaling path established by the INVITE message This message is sent to through P- CSCF. 15. forwards this message to the terminating endpoint. 16. The destination party may optionally perform alerting. If so, it signals this to the originating party by a provisional response indicating ringing. This message goes through,, and P-CSCF to arrive at the originating mobile. 12. Resources Reservation / BGCF/ Destinations 15. Success 16. Ringing 13. Reserve Success P-CSCF 14. Reserve Success Fig. 10. Mobile Origination (Part 3) 17. When the destination party answers, the terminating endpoint sends a S 200-OK final response. 18. The performs whatever service control is appropriate for the completed session setup. 19. The sends a S 200-OK final response through to P-CSCF. 20. The P-CSCF indicates the resources reserved for this session should now be committed. 21. P-CSCF sends a S 200-OK final response to the session originator 22. The originating mobile starts the media flow(s) for this session 22. Start Media Flow / BGCF/ Destinations OK 23. ACK OK 18. Service Control Fig. 11. Mobile Origination (Part 4) P-CSCF 23. The mobile responds to the 200 OK with a S ACK message, which goes through P- CSCF and. forwards the final ACK message to the terminating endpoint. Mobile Termination (Overview) Mobile termination is quite similar to the mobile origination except that the signaling is in the reverse direction. This scenario assumes that the mobile is located in a visited network. The use of the is, again, optional. If the originating network operator wants to keep the network configuration private, then the will choose an, who will perform firewall function and pass messages to the P- CSCF. 20. Approval of QoS Commit Fig. 12 shows an overview of the mobile termination procedure. The sequence is explained below: 1. INVITE: The originating party sends a S INVITE message through the network to the destination mobile. 2. SDP negotiation: The two end parties negotiate the media characteristics (e.g. number of media flows, codecs, etc.) for this OK 8

9 session and make a decision on the media streams they will support for this session. 3. Resource reservation: The network reserves the necessary resources for supporting this session, after the media characteristics for this session have been agreed on. 4. Session setup confirmation: Once resource reservation is completed successfully, the terminating mobile sends a S 200 OK final response and the originating point replies with a S ACK message to confirm the session setup. 5. Session in progress: Once the P-CSCF approves that the reserved resources can be used, the mobile starts the media flow. After the session setup is confirmed, the session is in progress. P-CSCF Originator the S signaling needs to be converted to legacy signaling such as ISDN Signaling User Part (ISUP). The is responsible for converting S signaling to legacy signaling such as ISUP. The is responsible for transporting ISUP signaling messages to a Trunking Signaling Gateway (T-SGW) over transport bearer. The T-SGW transports these ISUP messages over the SS7 bearer to either the or the legacy wireless networks. Please note that and T-SGW are logical functions. These functions may be implemented in one physical box. S - CSCF S Media Packet Network Legacy Signaling over transport Megaco T - SGW Legacy Signaling over SS7 transport MGW MGW MGW Vocoder Vocoder VocoderPCM PCM Stream Stream PCM Stream Stream Stream Stream Legacy Wireless Networks INVITE SDP Negotiation Resource Reservation Session Setup Confirmation (OK & ACK) Fig. 12. Session in Progress Mobile Termination (Overview) /Legacy Networks Interaction The IMS networks need to interact with so that IMS users can establish services to users. The architecture for supporting and legacy mobile networks is shown in the Fig. 13. The interworking between IMS networks and /legacy networks occur at two levels: One is the user plane level and the other is the signaling plane level. In the user plane, interworking elements are required to convert based media streams on the IMS side to PCM based media streams on the side. The Media Gateway (MGW) element is responsible for this function. The MGW elements are controlled by the Media Gateway Control Function () through the Megaco protocol. On the signaling plane level, Fig. 13. IMS-/legacy interworking The Fig. 14 shows an IMS mobile establishing a session with a phone on the. An overview of this session setup is described below. P-CSCF/ /BGCF 1. INVITE 3. SDP Negotiation 5. Resource Reservation 7. Ringing 10. Session Setup Confirm (OK + ACK) / T-SGW 2. Creates Context 11. Session in Progress MGW 4. Reserve Resources 6. Setup Trunks 8. Answer 9. Start Media Flow Fig. 14. Mobile to session setup 1. The initiates the session by sending a S INVITE request, which includes the initial SDP. This request is forwarded all the way to the. 2. The initiates a Megaco interaction to pick an outgoing channel and determine the media capabilities (e.g. encoding format) of the MGW. 9

10 3. The and the negotiate the media characteristics (e.g. number of media flows, codecs, etc.) for this session. 4. The initiates a Megaco interaction to modify the established connection and instruct the MGW to reserve the resources necessary for this session. 5. After determining the final set of media streams for this session, the initiates the reservation procedures for the resources needed for this session. Once the resources have been successfully reserved, the informs the. 6. The communicates with the through the T-SGW to set up trunks for this session. The MGCP uses the legacy protocol such as ISUP to setup trunks. 7. alerts the that the destination party has been contacted. 8. The informs the that the destination party has answered. 9. initiates a Megaco interaction to make the connection in the MGW bidirectional. 10. sends a S 200 OK final response and the originating replies with a S ACK message to confirm the session setup. 11. The starts the media flow for this session after it receives the S 200 OK response. Conclusion In this paper, we presented operations of UMTS Multimedia Subsystem. We explained the important procedures of the IMS such as service registration, origination, termination and the interaction with PTSN/legacy wireless networks. We also presented extensions introduced in IMS to S and SDP for supporting above operations. This paper has not addressed the handoff and roaming between IMS and legacy wireless networks. The interoperability between IMS and legacy wireless networks are not clearly defined in standards bodies yet. Another area for further study is the interaction of IMS with service elements such as S application servers, OSA servers and legacy Intelligent Networks (IN). These topics are areas of discussion for another paper when standards are completed. 1 RFC 2543 Session Initiation Protocol (S) 2 Advanced S Series: S and 3GPP, Narayan Parameshwar and Chris Reece, 3 RFC 3015 Megaco Protocol Version G TS : General Packet Radio Service (GPRS); Service description; Stage 2 5 3GPP TS : Multimedia (IM) Subsystem - Stage 1 6 3GPP TS : Multimedia (IM) Subsystem - Stage 2 7 3GPP TS : Multimedia (IM) Subsystem Cx Interface; Signaling Flows and Message Content The COPS (Common Open Policy Service) Protocol 9 3GPP TS : Multimedia (IM) Subsystem - Stage 3 10 Advanced S Series: Extending S, Gary Cote, About the Authors: As a Director of Product Management for Award Solutions, Narayan Parameshwar provides consulting and training in areas of cdma2000, UMTS, MPLS and Internet Telephony. As a Senior Consultant for Award Solutions, Lachu Aravamudhan provides consulting and training in UMTS, GPRS, and advanced wireless and Internet applications. As a Senior Consultant for Award Solutions, Chris Reece provides consulting and training in UMTS, Wireless Network Planning, Internet Telephony and Next Generation Networks. About Award Solutions: Award Solutions, Inc. is a premier provider of training, consulting, and development solutions. We are a "knowledge based" company rooted in the areas of advanced wireless and Internet technologies. Visit us at