Title of Invention	EFFICIENT IP NETWORKING SYSTEM AND METHODS FOR 3G WIRELESS MULTIMEDIA NETWORKS
Abstract	The present invention relates to efficient IP networking system and methods for 3G wireless multimedia networks. It proposes a Lightweight Multipurpose Signaling Protocol (LMPSP) for wireless multimedia networks. Though in the present invention it is used for 3G wireless multimedia networks, it can also be used for other types of wireless networks. This protocol provides efficient methods for the following purposes: same signaling message for multiple forward and reverse link flows, dynamic price management for wireless networks, mechanisms for aggregation of signaling messages for multiple flows. In addition, it also supports flow classification and QoS management. The present invention further, proposes four types of IP networking systems for 3G wireless multimedia networks. Here 30 wireless network is made more IP oriented. In addition to supporting QoS management and dynamic price management, it allows for easier management of wireless networks as similar IP protocols are run at all the nodes in the wireless networks for these purposes. Networking systems proposed here provide greater decoupling between the WER (I.e. PDSN) and the RN. The present invention also defines an LMPSP-RSVP proxy that allows LMPSP and RSVP to exist together in a network. In addition to managing QoS in wireless networks, it also allows for end-to-end QoS management in a network. Mechanisms used in these networking systems have been also described.

Title of Invention

EFFICIENT IP NETWORKING SYSTEM AND METHODS FOR 3G WIRELESS MULTIMEDIA NETWORKS

Abstract

The present invention relates to efficient IP networking system and methods for 3G wireless multimedia networks. It proposes a Lightweight Multipurpose Signaling Protocol (LMPSP) for wireless multimedia networks. Though in the present invention it is used for 3G wireless multimedia networks, it can also be used for other types of wireless networks. This protocol provides efficient methods for the following purposes: same signaling message for multiple forward and reverse link flows, dynamic price management for wireless networks, mechanisms for aggregation of signaling messages for multiple flows. In addition, it also supports flow classification and QoS management. The present invention further, proposes four types of IP networking systems for 3G wireless multimedia networks. Here 30 wireless network is made more IP oriented. In addition to supporting QoS management and dynamic price management, it allows for easier management of wireless networks as similar IP protocols are run at all the nodes in the wireless networks for these purposes. Networking systems proposed here provide greater decoupling between the WER (I.e. PDSN) and the RN. The present invention also defines an LMPSP-RSVP proxy that allows LMPSP and RSVP to exist together in a network. In addition to managing QoS in wireless networks, it also allows for end-to-end QoS management in a network. Mechanisms used in these networking systems have been also described.

Full Text	FIELD OF TECHNOLOGY This invention relates to the field of Wireless Multimedia Networl^s. This invention in general relates to the field of 3G Wireless Multimedia Networks. More particularly this invention encompasses the efficient IP Networking System and methods for 3G Wireless Multimedia Networks. PRESENT STATE OF ART A wireless multimedia network would typically support several types of applications such as multimedia conferencing, multimedia streaming, web browsing, games, File Transfer Protocol (FTP), Voice over Internet Phone (VoIP) etc. Some applications, such as, multimedia conferencing and streaming consist of several flows. Here, a flow can be a microflow or a macroflow. Here, a microflow is described via the following 5-tuple: IP source address, IP destination address. Layer 4 protocol type like Transmission Control Protocol (TCP), Universal Datagram Protocol (UDP) etc.. Layer 4 source port number, and Layer 4 destination port number. A macroflow is described via the following 3-tuple: IP source addresses, IP destination address, and Layer 4 protocol type. Multimedia applications can have the following types of flows: - Forward link data flow for audio (FLDF-A), - FonA^ard link data flow for video (FLDF-V), - Reverse link data flow for audio (RLDF-A), - Reverse link data flow for video (RLDF-V), - Forward link control flow for audio (FLCF-A), - FonA/ard link control flow for video (FLCF-V), - Reverse link control flow for audio (RLCF-A), - Reverse link control flow for video (RLCF-V). Here, fonA/ard link data flows (FLDFs) are : FLDF-A and FLDF-V. Reverse link data flows (RLDFs) are: RLDF-A and RLDF-V. Similarly, forward link control flows (FLCF) are: FLCF-A and FLCF-V. Reverse link control flows are: RLCF-A and RLCF-V. These control packets are used to provide feedback to the source and destination nodes about the received quality of audio and video flows. They are also used to control the rate at which data is sent from the source node to the destination node. Many data (and some control) flows have certain QoS requirements that are specified via some of the following parameters: delay bound, delay jitter, average delay, throughput, and packet loss. Some of the 3G wireless networking technologies are CDMA2000 IxEV-DV, CDMA2000 1xEV-D0 and WCDMA. A schematic diagram of a 3G network (specifically, CDMA2000 1xEV) is shown in Figure 1. Here, MS Is the mobile station, BS is the base station, PCF is the packet control function block and WER is the wireless edge router. An IP networking system for this type of networks is described in "wireless IP network standard", www.3gpp2.org 3GPP2 P.S0001-B. Figure 2 and 3 show existing 3G networking systems for simple IP and mobile IP respectively. BS and RN (Radio Network) are used interchangeably in the text below. The BS essentially includes the BSG and the BTS shown in the Figure 1. Initial session establishment between the MS and ON could be done via session level protocols (such as SIP - RFC3261, RTSP - RFC2326 described at the ww.ietf.org). A QoS signaling protocol, RSVP, has been described in "RSVP -RFC2205, www.ietf.org". As shown in Figure 4, RSVP sends Path message in the direction of data flow and Resv message in the opposite direction for each flow. For forward link flows, RSVP would require ON to generate RSVP Path message for each flow. In most of the cases, the ON in current networks does not support RSVP and thus cannot initiate RSVP path establishment. Also, the WER doesn't have knowledge of the session protocols exchanged between the ON and the MS, and thus cannot generate Path message on its own. For reverse link flows, the MS could generate RSVP Path message that needs to be sent to the ON. Again, ON could be a media server and may not support RSVP. In such situations, some mechanism is needed at the WER to decide whether or not to foHA/ard the Path message towards ON and transform the message in some format, as needed. For data and control path establishment between the WER-BSC (i.e. PDSN-BSC) and the BTS-MS, current 3G networking standards for CDMA2000 systems use A- interface messages as described in www.3gpp2.org. Also a PPP session is established between the MS and the PDSN (or WER). In this system, only the PDSN (or WER) has full visibility into the IP packet headers. LIMITATIONS Initial session establishment between the MS and the CN is usually done via IP protocols. There are following problems and limitations of the current IP protocols when used in 3G wireless multimedia networks : 1. An application has traffic profile (in terms of its peak rate, burstiness, long-term average rate) and QoS requirements (such as delay bound, delay jitter, average delay, throughput, loss) associated with it. The BTS needs to know about each application's traffic profile and QoS requirements to enable it to do proper resource allocation over the air interface between the BTS and the MS. The WER need to get flow classification information. The BSC also needs information related to flow classification, traffic profile and QoS requirements. An initial session between the MS and the CN could be established via some session level protocol (such as SIP, or RTSP). To exchange, flow classification, traffic characteristics and QoS requirement related information, one would usually want to consider using RSVP as the protocol between the MS and the CN. There are limitations of doing so in the 3G wireless networks. RSVP sends Path message In the direction of data flow and Resv message in the opposite direction for each flow. For forward link flows, RSVP would require CN to generate RSVP Path message for each flow. CN could be a media server in the Internet and many of the current Internet nodes do not support RSVP. In such situations, CN cannot generate this RSVP Path message. An efficient end-to-end IP networking system and lightweight wireless QoS management Protocols are needed for 3G wireless multimedia networks in such situations. This scenario is shown in Figure 5. 2. For reverse link flows, MS could generate RSVP Path message that needs to be sent to the CN. Again, CN could be a media server and may not support RSVP. In such situations, some mechanism is needed at the WER to decide whether or not to forward the Path message towards CN and transform the message in some format, as needed. Multimedia applications consist of large number of fonA/ard and reverse link flows and conservation of airlink resources while exchanging QoS signaling messages between the MS and the base station in 3G wireless multimedia networks is necessary. RSVP is not an efficient QoS signaling protocol for this purpose. For each flow, it needs a separate set of Path and Resv messages. It is a soft-state protocol. Once a session is established, it needs to keep on refreshing Path and Resv state at all the nodes. A multimedia conferencing application involves two fon/vard link audio and video RTP data flows, and two reverse link audio and video RTP data flows. It could also involve two fonA/ard link control (like RTCP) flows and two reverse link RTCP control flows. To provide per-flow QoS. RSVP would treat each of these flows separately and send messages for these independently. It would result in large number of messages per application in a 3G wireless network. Thus it is expensive to use RSVP over the airlink for multimedia applications in 3G wireless multimedia networks. Flow classification, traffic profile and QoS related information needs to be conveyed properly and efficiently to the WER, BSC and BTS for each flow. Current definition of interfaces does not have efficient methods of doing these. In a 3G network, time is typically divided into fixed length time slots. Each of these slots is of same length. For example, slot length in a CDMA2000 1xEV-DO networks is approximately 1.67 millisecond. Each mobile station informs the base station about the rate at which it can accept data in each of the slots on forward link. This rate can vary rapidly in a wide-area wireless network. There is a scheduler at the BTS that decides which fonA/ard link flow to serve in each slot. Thus a mobile station could be sometimes served when it is experiencing good channel conditions while sometimes it could be served when it is experiencing bad channel conditions. A network operator would charge mobile users for the service they receive. Some sort of pricing scheme is needed and it should also be possible to communicate it dynamically. It could consist of fixed component and variable component, and the variable component may need to be communicated to 3G network nodes during the lifetime of an application. Currently, this sort of option is not available in 3G networks. Thus, a pricing scheme along with ways to communicate is needed. 6. There is need to use IP protocols across various interfaces in 3G wireless networks. This would enable one to have an end-to-end all-IP network and reduce network operation, deployment and management cost. OBJECTS OF THE INVENTION It is the primary object of the invention to provide efficient IP networking systems for 3G wireless multimedia networks. It is another object of the invention to provide a lightweight multimedia signaling protocol for use in these efficient IP networking systems. It is another object of the invention to provide a system for making a 3G wireless network more IP oriented. It is another object of the invention to provide system, which allow easier end to end management of wireless networks. It is another object of the invention to provide system, which allow easier decoupling oftheWERandtheRN. It is another object of the invention to provide IP networking system where use of IP protocols on all the nodes provides greater flexibility in adding new features and keeps the deployment and operation costs low. Further objects of the invention will be apparent from the ensuing description. SUMMARY OF THE INVENTION The present invention first proposes a Lightweiglit IVIultipurpose Signaling Protocol (LMPSP) for 3G wireless nnultimedia networks. Though in the present invention it is used for 3G wireless networks, it can also be used for other types of wireless networks. This protocol provides efficient methods for the following purposes: Flow classification, QoS management and Dynamic price management for wireless networks The present invention further, proposes four types of IP networking systems for 3G wireless multimedia networks. In networking systems 1 and 2, PPP (Point-to-Point Protocol) endpoints are at the Mobile Station (MS) and the Wireless Edge Router (WER). In networking system 1, LMPSP is kept at the WER, Packet Control Function (PCF), BS and MS. This networking system is for the networks where It is already known that the Correspondent Node (CN) doesn't support RSVP (resource Reservation Protocol). Networking system 2 is a modification of the networking system 1 for the case where some of the nodes in a network may support RSVP also. In networking system 3 and 4, PPP endpoints are at the MS and the BS (or RN). LMPSP is kept at the WER, PCF. BS and MS. Networking system 3 is for the networks where the CN does not support RSVP. Networking system 4 is for the networks where some of the nodes may support RSVP. Here 3G wireless network is made more IP oriented. In addition to supporting QoS management and dynamic price management, it allows for easier management of wireless networks as it can run similar IP protocols at all the nodes in the wireless networks for these purposes. These networking systems provide greater flexibility and ease of management over other networking systems. All of the four networking systems proposed here use the lightweight multipurpose IP signaling protocol, LMPSP. With networking system 3 and 4, WER and RN are decoupled even to a greater extent as PPP is terminated at the RN instead of the WER. The present invention also defines an LMPSP-RSVP proxy that allows LMPSP and RSVP to exist together in a network. In addition to managing QoS in wireless networks, it also allows to do end-to-end QoS management in a network. Methods to process protocol messages for all these systems are also described for 3G wireless multimedia networks. The other objects, features and advantages of the present invention will be apparent from the accompanying drawings and the detailed description as follows : BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS Fig. 1 is a schematic diagram of a 3G-like networl^ in accordance with the existing art. Where MS is the mobile station, BSC is the base station controller, BTS is the base transceiver system and WER is the wireless edge router. In CDMA2000 1xEV systems, WER is the PDSN. For fonA^ard link flows, data is sent from the ON to the MS. For reverse link flows, data is sent from the MS to the ON. Fig. 2 is a schematic diagram of existing networking system in 3G networks where simple IP access is used. PPP session is established between the MS and the WER (i.e. PDSN). MS and WER (PDSN) have visibility into the IP packet headers. IP packets are segmented to small fixed size MAC packets. These MAC packets are transmitted over the air-interface between the MS and the RN. RLP (radio link protocol) end points are the MS and the RN. RLP is a modified form of the automatic repeat request protocol which is used to provide higher reliability at lower layers in 3G networks. Fig. 3 is a schematic diagram of existing Networking system in 3G networks where Mobile IP Access is used. PPP session is established between the MS and the WER (i.e. PDSN). MS and WER (PDSN) have visibility into the IP packet headers. Mobile IP is used. HA is the home agent. An IP tunnel is established between the WER and the HA. IP packets are segmented to small fixed size MAC packets. These MAC packets are transmitted over the air-interface between the MS and the RN. RLP (Radio link Protocol) end points are the MS and the RN. See above. Fig. 4 illustrates a network where RSVP sends Path message in the direction of data flow and Resv message in the opposite direction for each flow. RSVP, as a per-flow QoS signaling protocol, is defined in the RFC 2205. RSVP messages carry information related to flow classification, traffic characteristics, and QoS requirements. It also has policy objects that can be used to carry other types of information. Fig. 5 illustrates that many Internet nodes do not support RSVP and thus an end-to-end efficient IP networking system for 3G wireless multimedia networks is needed. Fig. 6 is a schematic diagram of Networking system I using Simple IP Access. LMPSP is placed above the IP layer at the MS, RN, PCF and WER. Fig. 7 is a schematic diagram of Networking system I using Mobile IP Access which illustrates to use the LMPSP at the MS, WER, PCF and RN. Fig. 8 is a structural diagram of modified GRE key as used by the networking systems proposed in the present invention. Fig, 9 illustrates the GRE keys and unique identifiers. It shows their exchange between two nodes in 3G networks. Fig. 10,11,12 and 13 illustrate the operation of Networking system I. Fig. 14 and15 illustrate the operation of Networking system II. Fig. 16,17,18,19, 20 and 21 illustrate the operation of Networking system II Case I. Fig. 22 and 23 illustrate the operation of Networking system II Case II. Fig 24, 25, 26 and 27 illustrate the operation of Networking system III. Fig 28, 29, 30 and 31 illustrate the operation of Networking system IV Case I. Fig 32, 33 and 34 illustrate the operation of Networking system IV Case 11, DETAILED DESCRIPTION OF THE INVENTION 1. Lightweight IVIultipurpose Signaling Protocol (LMPSP): The present invention first proposes a multipurpose lightweight signaling protocol which can be used for various purposes in wireless multimedia networks. It has mechanisms for the following: Multiple Flows per LMPSP Message A multimedia conferencing application consists of several flows. These include: forward link audio flow, reverse link audio flow, forward link video flow, reverse link video flow, fon/vard link audio and video control flows (like RTCP flows), and reverse link audio and video control flows (i.e. like RTCP flows). RSVP as in "RSVP -RFC2205" sends a separate set of Path and Resv messages for each of these flows. A separate set of refresh, error and tear down messages are also sent for each flow. The LMPSP protocol presented here uses only one set of messages for all the flows in an application. It allows one to send one message that includes information about all forward as well as reverse flows. There are following advantages: • As it allows one to combine messages for multiple flows in one signalling message, it reduces the size of messages as one doesn't have to repeat common information multiple times for these messages. This common information can include various fields such as source IP address, destination IP address, protocol version number, application identifier for all its constituent flows, type of layer 4 protocol for all the flows and some other fields. • One node can send request for multiple flows in an application at the same time and thus other nodes can decide whether or not they can provide required treatment to all the flows in that application. In the absence of this feature, there could be some gap between the arrival of requests of multiple flows belonging to the same application. In this case, a node could decide it can give required treatment to one flow of an application but later find out that it cannot give required treatment to another flow of the same application and thus it may need to send additional messages to take subsequent action, in our proposal, the LMPSP protocol is capable of carrying requests for multiple flows at the same time and thus a node can decide whether or not It can provide appropriate treatment for all the flows belonging to the same application. • It also allow an option using which one node can send information for multiple flows belonging to different applications to be sent to another node. Flow Classification and QoS Management LMPSP as proposed here is a multipurpose signalling protocol and is used for various purposes in the 3G wireless networking systems described here. It allows flows within an application to be classified based upon fields in the layer 3 and the layer 4 of the IP packet header and thus allows flow classification to be done. It allows sending signals for QoS management for multiple flows in the same message and thus allows for QoS management. Pricing It allows user to send signal in respect of the price one is ready to pay to the service provider. In a 3G network, each user informs the base station (or the RN) about the rate at which it is ready to receive data in each time slot. Similarly, each mobile station can send data only at some rate in each slot, depending upon its channel conditions. In the model presented here, each user is allowed to indicate the price as a function of data rate at the time when It is served. Thus a user could choose to pay higher price when it is served in a slot where it is asking for higher data rate than for a slot when it is selected to be served but is asking for lower data rate. User is also allowed to dynamically change this price by resending this updated information using the LMPSP signalling messages. User is also allowed to indicate different price profiles for different flows belonging to the same application. Flow Differentiation and Aggregation The present invention provides mechanisms in the LMPSP protocol using which the MS can convey to the WER and the BS whether or not to combine some flows for the purpose of QoS management. As mentioned earlier, a multimedia application can consist of several flows: FLDF-A, FLDF-V, RLDF-A, RLDF-V, FLCF-A, FLCF-V, RLCF-A and RLCF-V. The LMPSP protocol allows the MS to convey any of the following to the WER and the BS for the above multimedia conferencing application: 1. The MS can signal to the WER and the BS to treat all these eight flows separately for the purpose of QoS management in a multimedia conferencing application. 2. The MS can request the WER and the BS to do the following for the purpose of QoS management: Treat the four data flows (i.e. FLDF-A, FLDF-V, RLDF-A and RLDF-V) separately, Aggregate FLCF-A and FLCF-V, into one fonA^ard link control flow (FLCF) and aggregate the two reverse link control flows, RLCF-A and RLCF-V, into one reverse link control flows (RLCF). 3. The MS could request the WER and the BS to combine FLDF-A and FLDF-V into one fonA^ard link data flow (FLDF), and RLDF-A and RLDF-V into one reverse link data flow (RLDF). At the same time, it could request to aggregate FLCF-A and FLCF-V into one fon^^ard link control flow (FLCF), and RLCF-A and RLCF-V into one reverse link control flow (RLCF). Similarly, for multimedia streaming application, following are allowed: 1. Treat FLDF-A and FLDF-V separately. Aggregate FLCF-A and FLCF-V to FLCF. Aggregate RLCF-A and RLCF-V to RLCF. 2. Aggregate FLDF-A and FLDF-V to FLDF. Treat control flows as in the first option. 3. Treat FLDF-A, FLDF-V, FLCF-A, FLCF-V, RLCF-A and RLCF-V separately. Application Identifier It also provides a mechanism by which multiple applications running on a mobile are assigned different application identifiers and flows belonging to the same application can be identified via this application id. It provides the BS and the WER information that these flows belong to the same application and these nodes can take appropriate policy based decisions while running the QoS management algorithms. For example, one can use this application id to identify flows belonging to the same multimedia conferencing or streaming application. One could also use this to identify flows belonging to a multicast application. Multiple Transport Mechanisms LMPSP protocol packets can be carried using UDP or raw IP datagrams. In addition, different version, LI\/IPSP_TU, that uses TCP over the MS - WER hop and UDP (or raw IP datagrams) over the WER - PCF and the PCF - RN hops, is described. LMPSP Messages This protocol uses the following messages: • LMPSP_REQ: The LMPSP_REQ message conveys information for QoS management, flow classification and pricing for multiple flows. Relevant information for multiple forward as well as reverse link flows is conveyed in the same LMPSP_REQ message. It includes flow classification information (fields of layer 3 and layer 4 of IP packets that are used for flow classification), QoS profile (worst case delay, delay jitter, average delay, throughput and accepted loss of packets), traffic profile (peak rate, average rate and burstiness), and price profile (price that user would pay as a function of data rate at which it is served). Information for multiple flows belonging to different applications can be conveyed in the same message. To differentiate these, the message header includes the number of applications for which data is enclosed in the message. Within the LMPSP_REQ message, an application id TLV (in type, length and value format) is used to differentiate among multiple applications. The Type of this TLV indicates to other node that this field contains the application id. Within data for each application, flow id TLV is used to differentiate among multiple flows belonging to the same application. • LMPSP_ESTAB_DP_F: This message Is sent in the direction of forward link data flow from the WER to the PCF and/or from the PCF to the RN (to be specific, BSC in Figure 1). It carries some of the information needed to establish data path for flows on the WER-PCF and PCF-RN interfaces. Information for multiple fon/vard as well as reverse link flows is sent in the same message. Once data path has been established, these messages are sent to refresh or update state information (at PCF and RN, in the foHA^ard direction). • LMPSP_ESTAB__DP_R: This message is sent from the PCF to the WER and also, from the RN (to be specific, BSC in Figure 1) to the PCF. It carries some of the information needed to establish data path for flows on the PCF-WER and RN-PCF interfaces. It also carries response for the LMPSP_ESTAB_DP_F message. Once data path has been established, these messages are sent to refresh or update state information (at PCF and WER, in the reverse direction). • LMPSP_DP_REL: This message is sent from one node to another node to indicate that the application is being terminated and appropriate action should be taken to release the resources. • LMPSP_RESP: This message is sent from the WER to the MS and contains response of the LMPSP_REQ message which was sent by the MS to the WER. It indicates whether or not all the required operations such as traffic management (schedulers, admission control and congestion management modules), pricing and flow classification operations were successful. • LMPSP_UPDATE__REQ; This message is sent from one node to another node informing the other node about the updated information received. Each protocol message uses a common header. This header includes the following: - version number of the protocol - message type (one of the above listed messages) - message length (including the header length) ■ message checksum - number of applications for which it is carrying data ■ source and destination IP addresses After the above header, it contains information for each application. It includes a field which gives the number of flows for that application for which it is carrying data. For 1 r each flow, it includes a direction indicator for indicating whether it is a fonA^ard link or a reverse link flow. 2. Networking System I A novel networking system is described here, where the above LMPSP is used at the following nodes: MS, WER, PCF and RN (BSC to be specific). This is shown in Figure 6 and Figure 7, PCF could be part of WER or RN and is not shown explicitly in these figures here. It considers the case where the CN does not support RSVP. PPP session is established between the MS and the WER as described in Wireless IP Network Standard, www.3gDD2.org, 3GPP2 P.SOOOl-B. The operation of this networking system is described for multimedia applications. Similar steps can be used for other applications. Consider the case where the MS has initiated a session level request (such as SIP Invite or RTSP setup request) to the CN. We describe operation of networking system I here. These are shown in Figure 8, Figure 9, Figure 10. Figure 11, Figure 12, and Figure 13. 1. The MS initiates a session level request (such as SIP invite or RTSP setup). This is shown in the Figure 10. 2. The CN responds back with a response message (such as SIP or RTSP response message) as shown in the Figure 10. 3. The MS upon receiving the response message from the CN, starts a timer, T_wait_QoS_Sig. The MS waits to receive a QoS signalling message from the CN. If the MS does not receive an explicit QoS signalling message from the CN before the expiry of this timer, it sends a LMPSP_REQ message to the CN. Here the case is considered when the CN does not support RSVP and thus in the figure shown below, the MS does not receive a QoS signalling message (RSVP here) from the CN. In this message, the MS sends traffic profile, QoS profile, flow classification and pricing information for multiple ' forward and reverse link flows to the WER. Note that these multiple flows can belong to the same application or different applications. r 4. The WER processes information in the LI\/IPSP_REQ message and sends information for all the flows to the PCF to establish data path for these flows (as in Figure 10). For this purpose, the WER sends a LMPSP_ESTAB_DP_F message to the PCF. - The WER and the PCF sets up traffic management components for forward as well as reverse link flows. These components include: schedulers, admission control modules and congestion management modules. ■ Flow classification module is also set up using information in this message. - The WER assigns a unique number to each mobile to identify packets of that mobile on the WER-PCF interface. This mobile id is used locally by the WER and PCF. It further assigns application identifier and flow identifier for each flow for that mobile. It uses a GRE tunnel on the WER-PCF interface as in Wireless IP Network Standard, www.3gpp2.org. 3GPP2 P.SOOOl-B but structure of the GRE key is as shown in the Figure 8. Also, with this developed networking system, it is possible to carry GRE keys of multiple forwards as well as reverse link flows via the LMPSP messages on the WER-PCF interface. The WER assigns a unique GRE key for each reverse link flow that should be used by the PCF while sending data packet for that flow to the WER. - The WER also creates a unique identifier, which is called temp_fljd, for each forward link flow and informs the PCF about it. The PCF later uses this when it informs the WER about the status of its requests for specific treatment for those flows. It is only temporarily used for flow identification purposes and not used once the data path is established. Packets corresponding to fonA^ard link data path use GRE key that is assigned by the PCF. This is shown in Figure 9. Figure 9 shows a unique GRE key being assigned for each reverse link flow and a unique identifier for each forward link flow. This is marked as "A". A unique GRE key is assigned for each fonA^ard link flow. Also the FL identifier assigned by the WER is used to inform WER about the response of its LMPSP_ESTAB_DP_F message. Use GRE key Assigned by the WER for reverse link Flows. This is marked as "B". r WER maps GRE keys for FL flows and identifiers it assigned earlier for FL flows. GRE keys are only used in both the directions once the data path has been established." This is marked as "C". - After sending the LMPSP_ESTAB_DP_F message to the PCF, the WER also starts a timer, T_F__WER. If the WER does not receive a response of this message before the expiry of the timer, T_F_WER, it can retry sending the LI\/IPSP_ESTAB_DP_F message certain number of pre-specified times. Upon receiving a response of the LMPSP__ESTAB_DP_R message, it could also decide to modify certain parts of the request before sending this message again to the PCF, 5. The PCF upon receiving the LMPSP_ESTAB_DP_F message from the WER (as in Figure 11), does the following: ■ It processes the message and checks to ensure that it can provide the needed treatment to all the flows for which requests have been sent. - It creates unique mobile identifier to be used for that mobile on the PCF-RN interface. Note that this mobile id is of local significance only. It also assigns application id and flow id for each flow in that message. ■ it allocates unique GRE keys for all the reverse link flows in that message. This is the key that the PCF wants the RN to use while sending data packets on the reverse link to the PCF. Again, structure of the GRE key is same as that shown in the Figure 8. - PCF sends a LMPSP_ESTAB_DP_F message to the RN using the above information. - PCF also starts a timer, T_F_PCF, after sending the LMPSP_ESTAB_DP_F message to the RN. If the PCF does not receive response to its LMPSP_ESTAB_DP_F message before expiry of the T__F_PCF, it can resend this message to the RN a pre-specified number of times. 6. The RN upon receiving the LMPSP_ESTAB_DP_F message from the PCF does the following: - Creates a unique identifier for each reverse link flow. The MS has to use this while sending data packets to the RN on reverse link. These identifiers for v.. multiple flows are sent in the same message to the MS while doing channel establishment over the air. Checks to see if traffic management modules (schedulers, admission control etc.) can support involved flows and applications. - Performs channel establishment over the air with the MS following the process as in Wireless IP Network Standard, www.3gpp2.org, 3GPP2 P.S0001-B but adds unique identifier for each reverse link flow. 7. Once the RN knows that channel establishment over the RN-MS interface was successful, it sends a LMPSP_ESTAB_DP_R message to the PCF. This is shown in the Figure 11. This message does the following: ■ It acts as response message to the LMPSP__ESTAB_DP_F message, which was sent by the PCF to the RN. - The RN also creates unique GRE key for each fon/vard link flow and informs the PCF to use these while sending data in the forward direction for flows. - This message does not contain flow classification information as that was already sent from the PCF to the RN. It uses GRE keys that were assigned by the PCF for reverse link flows to identify the reverse link flows and indicate result of data path establishment process for these reverse link flows. For fonward link flows, it uses the unique identifier that was assigned by the PCF for that flow, to inform the PCF about its response of the data path establishment request. The PCF maps this Identifier and the GRE key assigned by the RN for fonA^ard link flows and starts using only the GRE key once the data path establishment is successful. 8. The PCF upon receiving the LMPSP_ESTAB_DP_R message from the RN, sends a LMPSP_ESTAB_DP_R message to the WER. This message acts as response message to the LMPSP_ESTAB_DP_F message which was sent by the WER to the PCF. The PCF also assigns unique GRE keys for each foHA/ard link flow and informs the WER to use these while sending data packets for forward link flow to the PCF. Again, keys of multiple flows to be sent in the same message are allowed. 9. The WER receives the LMPSP_ESTAB__DP_R message from the PCF and sends a response message, LMPSP_RESP to the MS. This is shown in the Figure 12. 10. Upon receiving the LMPSP_RESP message, the IVIS can indicate to the CN to start sending the data. The MS can also start sending data for reverse link flows. Once the MS or the CN decides to terminate the session, they exchange messages using the existing session level protocols such as SIP or RTSP. Upon receiving these terminating requests, the MS sends a LMPSP_REL message to the WER informing it to close sessions for these flows. Again, the LMPSP_REL messages are allowed to carry requests for multiple forward and reverse link flows at the same time. The WER in turn sends a LMPSP_REL message to the PCF which sends LMPSP___REL message to the RN. Each node which gets this message removes the state that was created earlier for these flows. This is shown in the Figure 13. Simulation of A11 and A9 messages: Note that the messages corresponding to All and A9 are not explicitly sent as given in Wireless IP Network Standard, www.3gpp2.org, 3GPP2 P.SOOOl-B. In the present networking system, these messages are not necessary. If one wants to keep these messages for backward compatibility, one could still do so without sending All and A9 messages explicitly. They can be simply simulated within the same node when it receives or sends an appropriate LMPSP message. 3. Networking System II In this networking system, consider a network where the CN supports RSVP. Like in networking system I, LMPSP is placed at the MS, WER, PCF and RN. PPP session is terminated at the MS and the WER. Refer to Figure 14 and Figure 15. Here, there are two cases to consider: First, when the CN's RSVP message arrives at the MS before the MS has sent the LMPSP_REQ message to the WER. Second, when the CN's RSVP message arrives at the MS after the MS has sent the LMPSP_REQ message to the WER. Case 1 It describes operational details of this networking system for the case where the RSVP Path message arrives at the MS before the MS has initiated the LMPSP_REQ message. These details are shown in Figure 16, Figure 17, Figure 18, Figure 19, Figure 20 and Figure 21. 1. The MS receives a SIP (or RTSP) response message from the CN (as shown in the Figure 16). It starts a timer, T_Walt_QoS„Sig. in the meantime, the CN sends an RSVP Path message towards the MS. The WER processes this Path message and sends an RSVP Path message to the MS. In Case I here, the MS receives the RSVP Path message before the expiry of the timer, T_Wait_QoS„Sig. 2. The MS uses this information and the information received via session level protocols (such as SIP, RTSP etc.) to create the LMPSP_REQ message. The MS is allowed to dynamically aggregate RSVP requests of multiple flows into one LMPSP_REQ message. There is a timer, T_Agg_MS, for this purpose. If the MS receives multiple requests during this period, it is allowed to aggregate those requests in the same LMPSP message. 3. As shown in the Figure 16, the MS sends LMPSP^REQ message to the WER. As described earlier, this message contains information for multiple foHA/ard and reverse link flows. 4. After these steps, the data path establishment steps are similar to the steps described in the networking system I. These are shown in Figure 17. 5. Once the data path has been established, the WER sends the LMPSP_RESP message to the MS as shown in Figure 18. 6. In the networking system here, the MS and the WER do not explicitly exchange RSVP messages to refresh their signalling state blocks. Instead, these are simulated internally at the MS and the WER as shown in Figure 18. These RSVP state blocks are not removed until LMPSP_REL message is received or the lifetime timers associated with these RSVP state blocks timeout. Other data flow details have been also shown In Figure 18. 7. Once the MS and the CN decide to close a session, the MS sends an LMPSP_REL message as shown in Figure 19. The MS also removes LMPSP and RSVP state blocks associated with the flows for which the session Is being terminated. 8. Other nodes (i.e. WER, PCF and RN) also remove state blocks associated with these flows. As RSVP Path message is sent per-flow only, it allow the MS to aggregate multiple RSVP Path requests (and associated SIP/RTSP requests) into the same LMPSP_REQ message using the dynamic aggregation feature of LMPSP. This is shown in Figure 20. WER doesn't remove the RSVP path state block until it receives the LMPSP_REL message RSVP path refresh is simulated locally at the WER. The MS is allowed to aggregate multiple RSVP path requests into one LMPSP_REQ message. The WER is allowed to aggregate responses for multiple flows into one LMPSP_RESP message. For reverse link flows, the MS initiates request via the LMPSP_REQ message, as described earlier. Once the WER receives this message, it may need to send RSVP messages towards the CN as the ON also supports RSVP in the network considered here. In this case, an LMPSP-RSVP proxy is placed at the WER. This proxy converts the LMPSP messages to the corresponding RSVP messages (and vice verse). Thus this proxy may generate multiple RSVP Path messages as a result of one LMPSP_REQ message and may aggregate RSVP Resv messages corresponding to multiple flows into one LMPSP_UPDATE_REQ message. This update message is sent from the WER to the MS, as shown in Figure 21, and informs the MS about the updates received from the CN. Case II Consider the case where the MS has sent the LMPSP_REQ message to the WER and then the MS receives an RSVP Path request from the CN. In this case, some of the data path establishment steps may have already been completed (or may be in progress). On receiving the RSVP Path message, the MS checks to see if some information needs to be changed and if needed, it informs the WER about this via an LMPSP_UPDATE_REQ message. The WER informs the PCF about this new piece information, wliich in turn conveys it to the RN. Refer to Figure 22 and Figure 23. Other steps involved are similar to those described in Case I above. 4- Networking System III In this networking system, PPP session between the MS and the RN is created. Thus, it terminates PPP at the RN instead of the WER as done in the earlier networking systems. It allows us to decouple functionality of the RN and the WER to a greater extent and provide greater flexibility in designing and managing networks. LMPSP is used at the MS, RN, PCF and WER. A network where the CN does not support RSVP is considered. Operational details are shown in Figure 24, Figure 25, Figure 26 and Figure 27, and described below : 1. PPP session is established between the MS and the RN only. Thus PPP is terminated at the RN. 2. The MS initiates LMPSP_REQ as shown in Figure 24, which is terminated at the RN. 3. The RN initiates the data path establishment over the MS-RN and the RN-PCF interface. The RN creates unique identifiers for each reverse link flow and asks the MS to use those while sending data packets for those flows on the reverse link. The RN also creates unique GRE key for each fonA^ard link flow and a unique identifier for each reverse link flow and informs these to the PCF via the LMPSP_ESTAB_DP_R message. It also conveys information that is used for flow classification, QoS management and pricing related decisions. 4. The PCF on receiving the LMPSP_ESTAB_DP_R message from the RN, creates unique GRE key for each forward link flow and unique identifier for each reverse link flow and informs about these to the WER via the LMPSP__ESTAB_DP___R message. These steps are shown in the Figure 24. 5. Upon receiving the LMPSP_ESTAB_DP_R message from the PCF, the WER processes it for traffic management, flow classification and pricing purposes. It also creates unique GRE key for each reverse link flow and informs the PCF about these by sending an LMPSP_ESTAB_DP_F message to the PCF. The WER also sends the unique identifiers that it has received for these flows from the PCF to allow the PCF to associate the GRE key created by the WER and the unique identifiers created by PCF for reverse link flows. To inform the PCF about the forward link flows, it uses the GRE keys that were assigned by the PCF for these fonA^ard link flows. These steps are shown in Figure 25 and Figure 27. Here a unique GRE key is assigned for each fonA/ard link flow and a unique identifier for each reverse link flow. This is marked as "A" in the Figure 27. A unique GRE key is assigned for each reverse link flow. Also the RL identifier assigned by the RN is used to inform RN about the response of its LMPSP_ESTAB_DP__R message GRE key Assigned by the RN is used for fonA/ard link Flows. This is marked as "B" in the Figure 27. RN maps GRE keys for RL flows and identifiers it assigned earlier for RL flows. Only GRE keys is used in both the directions once the data path has been established. This is marked as " C" in the Figure 27. 6. The RN sends a response message, LMPSP_RESP, once it finds out that data path has been established properly. Now, the CN and the MS start exchanging data for their flows. 7. Once the MS (or the CN) decides to close the application session, it sends an LMPSP_REL message to the RN, as shown in Figure 26 and removes LMPSP state associated with the flows for which the LMPSP_REL was initiated, 5, Networking System IV Here a network where the CN also supports RSVP is considered. As in networking system III, it establishes PPP session only between the MS and the RN. LMPSP is used at MS, RN, PCF and WER. Case I Operational details are shown in Figure 28, Figure 29, Figure 30 and Figure 31. These are described below: 1. The CN generates an RSVP Path message and sends it to the WER as shown in the Figure 28. 2. Here, one could use RSVP or LMPSP messages at the WER and the PCF. We describe the case where LIVIPSP is used at these nodes. The WER generates an LIVIPSP_UPDATE_REQ and sends it to the PCF which in turn conveys it to the RN. Finally, the MS is also informed about this. In case I here, this LMPSP_UPDATE_REQ reaches the MS before it has created an LMPSP^REQ message. 3. The MS can wait for some time at this stage and wait to see if it can aggregate multiple RSVP requests (and impact of SIP/RTSP protocol messages) into one request. 4. The MS generates LMPSP_REQ message and sends it to the RN. 5. Other operations details are shown in Figure 29, Figure 30 and Figure 31. Case II In this case, the MS receives an LMPSP_UPDATE_REQ message from the RN after the MS has already sent the LMPSP_REQ message to the RN. In such a case, it is possible that the RN, PCF and WER have already started doing data path establishment. In such a case, the MS can send an LMPSP_UPDATE_REQ message to the RN about updated information. The RN would in turn inform the PCF about this updated information. These steps are shown in Figure 32, Figure 33 and Figure 34. While the invention has been particularly described with reference to preferred embodiments, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention. GLOSSARY OF TERMS AND THEIR DEFINITIONS 3G: Third Generation wireless networks. These networks are to provide next generation mobile services with better quality of service and high speed Internet and multimedia services. These include networks such as CDMA2000 1xEV-D0, CDMA2000 1xEV-DV, WCDMA. BTS: Base Transceiver System. The air interface in 3G wireless networks terminates at the BTS and the mobile station. BSC: Base Station Controller CDMA: Code Division Multiple Access. It is a spread-spectrum technology allowing many users to occupy the same time and frequency allocations in a given band/space. It assigns unique codes to each communication to differentiate it from others in the same spectrum. CDMA2000 1xEV: This includes CDMA2000 IxEV-DO and CDMA2000 1xEV-DV. CDMA2000 1xEV-D0: CDMA2000 Single Carrier Evolution, Data Optimized. It delivers peak data rates of 2.4 Mbps and is intended to provide high performance and low cost packet data services. CDMA2000 1xEV-DV: CDMA2000, Single Carrier, Evolution, Data and Voice. It provides integrated voice and simultaneous high-speed packet data multimedia services. Correspondent Node (CN): It is a node with which the MS is communicating. For example, it could be a multimedia server or some other mobile station. Forward link flows: These flows are sending data packets from CN (or WER) towards the MS. FTP: File Transfer Protocol. A widely used protocol in the internet used to transfer files from one point to another point. HTTP: Hyper-Text Transfer Protocol. A protocol widely used for web browsing applications in the internet. IP: Internet Protocol. A layer 3 protocol widely used in the internet. LCP: Link Control Protocol. It is used to negotiate radio link protocol and options to control the session in CDMA2000 wireless networks. MPEG: Moving Picture Experts Group. There are several MPEG standards such as MPEG-4, MPEG-2 etc. MS: Mobile Station NACK: Negative Acknowledgement. In contrast to positive acknowledgements, NACK is typically sent when a packet is not received within some expected time interval. QoS (Quality of Service): Applications have different types of requirements and these should be met by the networks. These include delay bound, delay jitter, required rate, packet loss, and average delay. Reverse link flows: These flows are sending data from the MS towards the CN (or WER). RLP: Radio Link Protocol. It is a modified form of the automatic repeat request (ARQ) protocol and used in 3G networks to improve reliability of the air-interface. RN: Radio network consisting of BSC and BTS. We use it interchangeably with BS (base station). RSVP: Resource Reservation Protocol. It is a QoS signaling protocol specified in the RFC2205 and available at www.ietf.org RTSP: Real Time Streaming Protocol. This is used to establish session for streaming applications in internet. SCP: Stream Control Protocol. This is used for sending RLP negative acknowledgements in CDMA2000 networks when missing RLP data is detected. SIP: Session Initiation Protocol. This session level protocol is used to establish sessions for streaming/conferencing applications in Internet. TCP: Transport Control Protocol. A layer 4 protocol widely used in the internet. VoIP: Voice over IP WCDMA: Wideband Code Division Multiple Access WER: Wireless Edge Router WE CLAIM 1. An efficient IP networking system for 3G wireless multimedia networks managing QoS, comprising liglitweight multipurpose signaling protocol (LMPSP); means for Flow classification, QoS management and Dynamic price management for wireless networks; means for Flow Differentiation and Aggregation, means for sending a single message that includes information about all forward as well as reverse flows, and means for assigning different application identifiers to multiple applications running on a mobile. 2. A networking system as claimed in claim 1, wherein when the Correspondent Node (CN) does not support RSVP, PPP endpoints are at the Mobile Station (MS) and the Wireless Edge Router (WER), in that LMPSP is kept at the WER, Packet Control Function (PCF), BS and MS. 3. A networking system as claimed in claim 1, wherein when the CN supports RSVP, LMPSP is kept at the MS, WER, PCF and RN and PPP session is terminated at the MS and the WER. 4. A networking system as claimed in claim 1, wherein PPP session is between the MS and the RN, LMPSP is kept at the MS, RN, PCF and WER and the CN does not support RSVP. 5. A networking system as claimed in claim 1, wherein the CN also supports RSVP; PPP session is only between the MS and the RN and LMPSP is used at MS, RN, PCF and WER. 6. A method for efficiently implementing quality of service (QoS) for an internet protocol (IP) network, said method comprising the steps of providing a Lightweight Multipurpose Signaling Protocol (LMPSP) for wireless networks to efficiently carry out the following functions namely, flow classification, QoS management, and dynamic price management for wireless networks; sending one message that includes information about all forward as well as reverse flows; carrying out Flow Differentiation and Aggregation in that the MS conveys information to the WER and r the BS regarding combining some flows for the purpose of QoS management; multiple applications running on a mobile are assigned different application Identifiers and LMPSP protocol packets are carried using UDP or raw IP datagrams. 7. A method for efficiently implementing quality of service (QoS) for an internet protocol (IP) network as claimed in claim 6, wherein in addition to managing QoS in wireless networks, for end-to-end QoS management in a network, a LMPSP-RSVP proxy isplaced at the WER which allows LMPSP and RSVP to exist together in a network and converts the LMPSP messages to the corresponding RSVP messages and vice verse and further this proxy generates multiple RSVP Path messages as a result of one LMPSP_REQ message and aggregates RSVP Resv messages corresponding to multiple flows into one LMPSP_UPDATE_REQ message. 8. A method as claimed in claim 6, wherein a networking system is provided where when the Correspondent Node (CN) does not support RSVP, PPP endpoints are at the Mobile Station (MS) and the Wireless Edge Router (WER), in that LMPSP is kept at the WER, Packet Control Function (PCF), BS and MS. 9. A method as claimed in claim 6 comprising the following detailed steps of : a) MS initiates a session level request; b) The CN responds back with a response message; c) MS upon receiving the response message from the CN, starts a timer, and sends a LMPSP_REQ message to the CN; d) The MS sends traffic profile, QoS profile, flow classification and pricing information for multiple forward and reverse link flows to the WER; e) The WER processes information in the LMPSP_REQ message and sends information for all the flows using LMPSP_ESTAB_DP_F message to the PCF to establish data path for these flows and the WER also starts a timer, T.F_WER; f) The WER and the PCF set up traffic management components viz. schedulers; admission control, flow classification and congestion management modules forfonA/ard as well as reverse link flows; g) The WER assigns a unique number to each mobile to identify packets of that mobile on the WER-PCF interface and further assigns application identifier and flow identifier for each flow for that mobile; h) The WER assigns a unique GRE key for each reverse link flow that should be used by the PCF while sending data packet for that flow to the WER; i) The WER also creates a unique identifier, for each forward link flow and informs the PCF about it. And after sending the LMPSP_ESTAB_DP__F message to the PCF; j) The PCF upon receiving the LMPSP_ESTAB_DP_F message from the WER, processes it and sends it to RN; k) The RN upon receiving the LMPSP_ESTAB_DP_F message from the PCF processes it and once the channel establishment over the RN-MS interface was successful, it sends a LMPSP_ESTAB__DP_R message to the PCF; I) The PCF upon receiving the LMPSP_ESTAB_DP_R message from the RN, sends a LMPSP__ESTAB_DP_R message to the WER; m) The WER on receiving the LMPSP_ESTAB_DP_R message from the PCF sends a response message, LMPSP_RESP to the MS; n) Upon receiving the LMPSP_RESP message, the MS indicates to the CN to start sending the data. And MS can also start sending data for reverse link flows. 10, A method as claimed in claim 9, wherein for backward compatibility A11 and A9 messages are simulated within the same node when it receives or sends an appropriate LMPSP message. 11. A method as claimed in claim 6, wherein to decouple functionality of the RN and the WER to a greater extent and provide greater flexibility in designing and managing networks where the CN does not support RSVP the following steps are carried out: a) The MS initiates LMPSP_REQ which is terminated at the RN; b) The RN initiates the data path establishment over the MS-RN and the RN-PCF interface; c) The RN creates unique identifiers for each reverse link flow and requests the MS to use those while sending data packets for those flows on the reverse > link and also creates unique GRE key for each fonA/ard link flow and a unique identifier for each reverse link flow and send the information to the PCF via the LMPSP_ESTAB_DP_R message; d) RN also conveys information that is used for flow classification, QoS management and pricing related decisions; e) The PCF on receiving the LMPSP_ESTAB_DP_R message from the RN, creates unique GRE key for each fonA/ard link flow and unique identifier for each reverse link flow and informs the WER via the LMPSP„ESTAB_DP_R message; f) The WER processes the LMPSP_ESTAB_DP_R message from the PCF for traffic management, flow classification and pricing purposes and also creates unique GRE key for each reverse link flow and informs the PCF by sending an LMPSP_ESTAB_DP_F message to the PCF; g) The WER also sends the unique identifiers received for these flows from the PCF to allow the PCF to associate the GRE key created by the WER and the unique identifiers created by PCF for reverse link flows; h) using the GRE keys that were assigned by the PCF for these fon/vard link flows it informs the PCF about the forward link flows; i) The RN sends a response message, LMPSP_RESP once the data path has been established properly and the CN and the MS start exchanging data for their flows. 12. A method as claimed in claim 6, wherein the CN also supports RSVP and the following steps are carried out: a) The CN generates an RSVP Path message and sends it to the WER; b) LMPSP is used at the nodes and the WER generates an LMPSP_UPDATE_REQ and sends it to the PCF which in turn conveys it to the RN and finally to MS; c) The MS waits for some time at this stage to decide if it can aggregate multiple RSVP requests and impact of SIP/RTSP protocol messages) into one request. And then generates LMPSP_REQ message and sends it to the RN. 13. A method as claimed in claim 6, wherein a networking system is provided where CN does not supports RSVP; PPP session is established between the MS and the RN only and LMPSP is used at the MS, RN, PCF and WER. 14. A method as claimed in claim 6, wherein when the CN supports RSVP, LMPSP is kept at the MS, WER, PCF and RN and wherein PPP session is terminated at the MS and the WER. 15. A method as claimed in claim 6, wherein a networking system is provided where the CN also supports RSVP. PPP session is only between the MS and the RN and LMPSP is used at MS, RN, PCF and WER in that WER and the RN are decoupled to a greater extent. 16. An efficient IP Networking System for 3G wireless multimedia networks substantially as herein described particularly with reference to the drawings. 17. The efficient methods for IP Networking for 3G Wireless Multimedia Networking systems substantially as herein described particularly with reference to the drawings.

Full Text

FIELD OF TECHNOLOGY
This invention relates to the field of Wireless Multimedia Networl^s. This invention in general relates to the field of 3G Wireless Multimedia Networks. More particularly this invention encompasses the efficient IP Networking System and methods for 3G Wireless Multimedia Networks.
PRESENT STATE OF ART
A wireless multimedia network would typically support several types of applications such as multimedia conferencing, multimedia streaming, web browsing, games, File Transfer Protocol (FTP), Voice over Internet Phone (VoIP) etc. Some applications, such as, multimedia conferencing and streaming consist of several flows. Here, a flow can be a microflow or a macroflow. Here, a microflow is described via the following 5-tuple: IP source address, IP destination address. Layer 4 protocol type like Transmission Control Protocol (TCP), Universal Datagram Protocol (UDP) etc.. Layer 4 source port number, and Layer 4 destination port number. A macroflow is described via the following 3-tuple: IP source addresses, IP destination address, and Layer 4 protocol type. Multimedia applications can have the following types of flows:
- Forward link data flow for audio (FLDF-A),
- FonA^ard link data flow for video (FLDF-V),
- Reverse link data flow for audio (RLDF-A),
- Reverse link data flow for video (RLDF-V),
- Forward link control flow for audio (FLCF-A),
- FonA/ard link control flow for video (FLCF-V),
- Reverse link control flow for audio (RLCF-A),
- Reverse link control flow for video (RLCF-V).
Here, fonA/ard link data flows (FLDFs) are : FLDF-A and FLDF-V. Reverse link data flows (RLDFs) are: RLDF-A and RLDF-V. Similarly, forward link control flows (FLCF) are: FLCF-A and FLCF-V. Reverse link control flows are: RLCF-A and RLCF-V. These control packets are used to provide feedback to the source and destination nodes about the received quality of audio and video flows. They are also used to

control the rate at which data is sent from the source node to the destination node. Many data (and some control) flows have certain QoS requirements that are specified via some of the following parameters: delay bound, delay jitter, average delay, throughput, and packet loss.
Some of the 3G wireless networking technologies are CDMA2000 IxEV-DV, CDMA2000 1xEV-D0 and WCDMA. A schematic diagram of a 3G network (specifically, CDMA2000 1xEV) is shown in Figure 1. Here, MS Is the mobile station, BS is the base station, PCF is the packet control function block and WER is the wireless edge router. An IP networking system for this type of networks is described in "wireless IP network standard", www.3gpp2.org 3GPP2 P.S0001-B. Figure 2 and 3 show existing 3G networking systems for simple IP and mobile IP respectively. BS and RN (Radio Network) are used interchangeably in the text below. The BS essentially includes the BSG and the BTS shown in the Figure 1.
Initial session establishment between the MS and ON could be done via session level protocols (such as SIP - RFC3261, RTSP - RFC2326 described at the ww.ietf.org). A QoS signaling protocol, RSVP, has been described in "RSVP -RFC2205, www.ietf.org". As shown in Figure 4, RSVP sends Path message in the direction of data flow and Resv message in the opposite direction for each flow. For forward link flows, RSVP would require ON to generate RSVP Path message for each flow. In most of the cases, the ON in current networks does not support RSVP and thus cannot initiate RSVP path establishment. Also, the WER doesn't have knowledge of the session protocols exchanged between the ON and the MS, and thus cannot generate Path message on its own.
For reverse link flows, the MS could generate RSVP Path message that needs to be sent to the ON. Again, ON could be a media server and may not support RSVP. In such situations, some mechanism is needed at the WER to decide whether or not to foHA/ard the Path message towards ON and transform the message in some format, as needed.
For data and control path establishment between the WER-BSC (i.e. PDSN-BSC) and the BTS-MS, current 3G networking standards for CDMA2000 systems use A-

interface messages as described in www.3gpp2.org. Also a PPP session is established between the MS and the PDSN (or WER). In this system, only the PDSN (or WER) has full visibility into the IP packet headers.
LIMITATIONS
Initial session establishment between the MS and the CN is usually done via IP protocols. There are following problems and limitations of the current IP protocols when used in 3G wireless multimedia networks :
1. An application has traffic profile (in terms of its peak rate, burstiness, long-term average rate) and QoS requirements (such as delay bound, delay jitter, average delay, throughput, loss) associated with it. The BTS needs to know about each application's traffic profile and QoS requirements to enable it to do proper resource allocation over the air interface between the BTS and the MS. The WER need to get flow classification information. The BSC also needs information related to flow classification, traffic profile and QoS requirements. An initial session between the MS and the CN could be established via some session level protocol (such as SIP, or RTSP). To exchange, flow classification, traffic characteristics and QoS requirement related information, one would usually want to consider using RSVP as the protocol between the MS and the CN. There are limitations of doing so in the 3G wireless networks. RSVP sends Path message In the direction of data flow and Resv message in the opposite direction for each flow. For forward link flows, RSVP would require CN to generate RSVP Path message for each flow. CN could be a media server in the Internet and many of the current Internet nodes do not support RSVP. In such situations, CN cannot generate this RSVP Path message. An efficient end-to-end IP networking system and lightweight wireless QoS management Protocols are needed for 3G wireless multimedia networks in such situations. This scenario is shown in Figure 5.
2. For reverse link flows, MS could generate RSVP Path message that needs to be sent to the CN. Again, CN could be a media server and may not support RSVP. In such situations, some mechanism is needed at the WER to decide

whether or not to forward the Path message towards CN and transform the message in some format, as needed.
Multimedia applications consist of large number of fonA/ard and reverse link flows and conservation of airlink resources while exchanging QoS signaling messages between the MS and the base station in 3G wireless multimedia networks is necessary. RSVP is not an efficient QoS signaling protocol for this purpose. For each flow, it needs a separate set of Path and Resv messages. It is a soft-state protocol. Once a session is established, it needs to keep on refreshing Path and Resv state at all the nodes. A multimedia conferencing application involves two fon/vard link audio and video RTP data flows, and two reverse link audio and video RTP data flows. It could also involve two fonA/ard link control (like RTCP) flows and two reverse link RTCP control flows. To provide per-flow QoS. RSVP would treat each of these flows separately and send messages for these independently. It would result in large number of messages per application in a 3G wireless network. Thus it is expensive to use RSVP over the airlink for multimedia applications in 3G wireless multimedia networks.
Flow classification, traffic profile and QoS related information needs to be conveyed properly and efficiently to the WER, BSC and BTS for each flow. Current definition of interfaces does not have efficient methods of doing these.
In a 3G network, time is typically divided into fixed length time slots. Each of these slots is of same length. For example, slot length in a CDMA2000 1xEV-DO networks is approximately 1.67 millisecond. Each mobile station informs the base station about the rate at which it can accept data in each of the slots on forward link. This rate can vary rapidly in a wide-area wireless network. There is a scheduler at the BTS that decides which fonA/ard link flow to serve in each slot. Thus a mobile station could be sometimes served when it is experiencing good channel conditions while sometimes it could be served when it is experiencing bad channel conditions. A network operator would charge mobile users for the service they receive. Some sort of pricing scheme is needed and it should also be possible to communicate it dynamically. It

could consist of fixed component and variable component, and the variable component may need to be communicated to 3G network nodes during the lifetime of an application. Currently, this sort of option is not available in 3G networks. Thus, a pricing scheme along with ways to communicate is needed.
6. There is need to use IP protocols across various interfaces in 3G wireless networks. This would enable one to have an end-to-end all-IP network and reduce network operation, deployment and management cost.
OBJECTS OF THE INVENTION
It is the primary object of the invention to provide efficient IP networking systems for 3G wireless multimedia networks.
It is another object of the invention to provide a lightweight multimedia signaling protocol for use in these efficient IP networking systems.
It is another object of the invention to provide a system for making a 3G wireless network more IP oriented.
It is another object of the invention to provide system, which allow easier end to end management of wireless networks.
It is another object of the invention to provide system, which allow easier decoupling oftheWERandtheRN.
It is another object of the invention to provide IP networking system where use of IP protocols on all the nodes provides greater flexibility in adding new features and keeps the deployment and operation costs low.
Further objects of the invention will be apparent from the ensuing description.

SUMMARY OF THE INVENTION
The present invention first proposes a Lightweiglit IVIultipurpose Signaling Protocol (LMPSP) for 3G wireless nnultimedia networks. Though in the present invention it is used for 3G wireless networks, it can also be used for other types of wireless networks. This protocol provides efficient methods for the following purposes: Flow classification, QoS management and Dynamic price management for wireless networks
The present invention further, proposes four types of IP networking systems for 3G wireless multimedia networks. In networking systems 1 and 2, PPP (Point-to-Point Protocol) endpoints are at the Mobile Station (MS) and the Wireless Edge Router (WER). In networking system 1, LMPSP is kept at the WER, Packet Control Function (PCF), BS and MS. This networking system is for the networks where It is already known that the Correspondent Node (CN) doesn't support RSVP (resource Reservation Protocol). Networking system 2 is a modification of the networking system 1 for the case where some of the nodes in a network may support RSVP also. In networking system 3 and 4, PPP endpoints are at the MS and the BS (or RN). LMPSP is kept at the WER, PCF. BS and MS. Networking system 3 is for the networks where the CN does not support RSVP. Networking system 4 is for the networks where some of the nodes may support RSVP. Here 3G wireless network is made more IP oriented. In addition to supporting QoS management and dynamic price management, it allows for easier management of wireless networks as it can run similar IP protocols at all the nodes in the wireless networks for these purposes. These networking systems provide greater flexibility and ease of management over other networking systems. All of the four networking systems proposed here use the lightweight multipurpose IP signaling protocol, LMPSP. With networking system 3 and 4, WER and RN are decoupled even to a greater extent as PPP is terminated at the RN instead of the WER. The present invention also defines an LMPSP-RSVP proxy that allows LMPSP and RSVP to exist together in a network. In addition to managing QoS in wireless networks, it also allows to do end-to-end QoS management in a network. Methods to process protocol messages for all these systems are also described for 3G wireless multimedia networks.

The other objects, features and advantages of the present invention will be apparent from the accompanying drawings and the detailed description as follows :
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
Fig. 1 is a schematic diagram of a 3G-like networl^ in accordance with the existing art. Where MS is the mobile station, BSC is the base station controller, BTS is the base transceiver system and WER is the wireless edge router. In CDMA2000 1xEV systems, WER is the PDSN. For fonA^ard link flows, data is sent from the ON to the MS. For reverse link flows, data is sent from the MS to the ON.
Fig. 2 is a schematic diagram of existing networking system in 3G networks where simple IP access is used. PPP session is established between the MS and the WER (i.e. PDSN). MS and WER (PDSN) have visibility into the IP packet headers. IP packets are segmented to small fixed size MAC packets. These MAC packets are transmitted over the air-interface between the MS and the RN. RLP (radio link protocol) end points are the MS and the RN. RLP is a modified form of the automatic repeat request protocol which is used to provide higher reliability at lower layers in 3G networks.
Fig. 3 is a schematic diagram of existing Networking system in 3G networks where Mobile IP Access is used. PPP session is established between the MS and the WER (i.e. PDSN). MS and WER (PDSN) have visibility into the IP packet headers. Mobile IP is used. HA is the home agent. An IP tunnel is established between the WER and the HA. IP packets are segmented to small fixed size MAC packets. These MAC packets are transmitted over the air-interface between the MS and the RN. RLP (Radio link Protocol) end points are the MS and the RN. See above.
Fig. 4 illustrates a network where RSVP sends Path message in the direction of data flow and Resv message in the opposite direction for each flow. RSVP, as a per-flow QoS signaling protocol, is defined in the RFC 2205. RSVP messages carry information related to flow classification, traffic characteristics, and QoS requirements. It also has policy objects that can be used to carry other types of information.

Fig. 5 illustrates that many Internet nodes do not support RSVP and thus an end-to-end efficient IP networking system for 3G wireless multimedia networks is needed.
Fig. 6 is a schematic diagram of Networking system I using Simple IP Access. LMPSP is placed above the IP layer at the MS, RN, PCF and WER.
Fig. 7 is a schematic diagram of Networking system I using Mobile IP Access which illustrates to use the LMPSP at the MS, WER, PCF and RN.
Fig. 8 is a structural diagram of modified GRE key as used by the networking systems proposed in the present invention.
Fig, 9 illustrates the GRE keys and unique identifiers. It shows their exchange between two nodes in 3G networks.
Fig. 10,11,12 and 13 illustrate the operation of Networking system I.
Fig. 14 and15 illustrate the operation of Networking system II.
Fig. 16,17,18,19, 20 and 21 illustrate the operation of Networking system II Case I.
Fig. 22 and 23 illustrate the operation of Networking system II Case II.
Fig 24, 25, 26 and 27 illustrate the operation of Networking system III.
Fig 28, 29, 30 and 31 illustrate the operation of Networking system IV Case I.
Fig 32, 33 and 34 illustrate the operation of Networking system IV Case 11,
DETAILED DESCRIPTION OF THE INVENTION
1. Lightweight IVIultipurpose Signaling Protocol (LMPSP):
The present invention first proposes a multipurpose lightweight signaling protocol which can be used for various purposes in wireless multimedia networks. It has mechanisms for the following:

Multiple Flows per LMPSP Message
A multimedia conferencing application consists of several flows. These include: forward link audio flow, reverse link audio flow, forward link video flow, reverse link video flow, fon/vard link audio and video control flows (like RTCP flows), and reverse link audio and video control flows (i.e. like RTCP flows). RSVP as in "RSVP -RFC2205" sends a separate set of Path and Resv messages for each of these flows. A separate set of refresh, error and tear down messages are also sent for each flow. The LMPSP protocol presented here uses only one set of messages for all the flows in an application. It allows one to send one message that includes information about all forward as well as reverse flows. There are following advantages:
• As it allows one to combine messages for multiple flows in one signalling message, it reduces the size of messages as one doesn't have to repeat common information multiple times for these messages. This common information can include various fields such as source IP address, destination IP address, protocol version number, application identifier for all its constituent flows, type of layer 4 protocol for all the flows and some other fields.
• One node can send request for multiple flows in an application at the same time and thus other nodes can decide whether or not they can provide required treatment to all the flows in that application. In the absence of this feature, there could be some gap between the arrival of requests of multiple flows belonging to the same application. In this case, a node could decide it can give required treatment to one flow of an application but later find out that it cannot give required treatment to another flow of the same application and thus it may need to send additional messages to take subsequent action, in our proposal, the LMPSP protocol is capable of carrying requests for multiple flows at the same time and thus a node can decide whether or not It can provide appropriate treatment for all the flows belonging to the same application.
• It also allow an option using which one node can send information for multiple flows belonging to different applications to be sent to another node.

Flow Classification and QoS Management
LMPSP as proposed here is a multipurpose signalling protocol and is used for various purposes in the 3G wireless networking systems described here. It allows flows within an application to be classified based upon fields in the layer 3 and the layer 4 of the IP packet header and thus allows flow classification to be done. It allows sending signals for QoS management for multiple flows in the same message and thus allows for QoS management.
Pricing
It allows user to send signal in respect of the price one is ready to pay to the service provider. In a 3G network, each user informs the base station (or the RN) about the rate at which it is ready to receive data in each time slot. Similarly, each mobile station can send data only at some rate in each slot, depending upon its channel conditions.
In the model presented here, each user is allowed to indicate the price as a function of data rate at the time when It is served. Thus a user could choose to pay higher price when it is served in a slot where it is asking for higher data rate than for a slot when it is selected to be served but is asking for lower data rate. User is also allowed to dynamically change this price by resending this updated information using the LMPSP signalling messages.
User is also allowed to indicate different price profiles for different flows belonging to the same application.
Flow Differentiation and Aggregation
The present invention provides mechanisms in the LMPSP protocol using which the MS can convey to the WER and the BS whether or not to combine some flows for the purpose of QoS management. As mentioned earlier, a multimedia application can consist of several flows: FLDF-A, FLDF-V, RLDF-A, RLDF-V, FLCF-A, FLCF-V, RLCF-A and RLCF-V. The LMPSP protocol allows the MS to convey any of the following to the WER and the BS for the above multimedia conferencing application:

1. The MS can signal to the WER and the BS to treat all these eight flows separately for the purpose of QoS management in a multimedia conferencing application.
2. The MS can request the WER and the BS to do the following for the purpose of QoS management: Treat the four data flows (i.e. FLDF-A, FLDF-V, RLDF-A and RLDF-V) separately, Aggregate FLCF-A and FLCF-V, into one fonA^ard link control flow (FLCF) and aggregate the two reverse link control flows, RLCF-A and RLCF-V, into one reverse link control flows (RLCF).
3. The MS could request the WER and the BS to combine FLDF-A and FLDF-V into one fonA^ard link data flow (FLDF), and RLDF-A and RLDF-V into one reverse link data flow (RLDF). At the same time, it could request to aggregate FLCF-A and FLCF-V into one fon^^ard link control flow (FLCF), and RLCF-A and RLCF-V into one reverse link control flow (RLCF).
Similarly, for multimedia streaming application, following are allowed:
1. Treat FLDF-A and FLDF-V separately. Aggregate FLCF-A and FLCF-V to FLCF. Aggregate RLCF-A and RLCF-V to RLCF.
2. Aggregate FLDF-A and FLDF-V to FLDF. Treat control flows as in the first option.
3. Treat FLDF-A, FLDF-V, FLCF-A, FLCF-V, RLCF-A and RLCF-V separately.
Application Identifier
It also provides a mechanism by which multiple applications running on a mobile are assigned different application identifiers and flows belonging to the same application can be identified via this application id. It provides the BS and the WER information that these flows belong to the same application and these nodes can take appropriate policy based decisions while running the QoS management algorithms. For example, one can use this application id to identify flows belonging to the same multimedia conferencing or streaming application. One could also use this to identify flows belonging to a multicast application.

Multiple Transport Mechanisms
LMPSP protocol packets can be carried using UDP or raw IP datagrams. In addition, different version, LI\/IPSP_TU, that uses TCP over the MS - WER hop and UDP (or raw IP datagrams) over the WER - PCF and the PCF - RN hops, is described.
LMPSP Messages
This protocol uses the following messages:
• LMPSP_REQ: The LMPSP_REQ message conveys information for QoS management, flow classification and pricing for multiple flows. Relevant information for multiple forward as well as reverse link flows is conveyed in the same LMPSP_REQ message. It includes flow classification information (fields of layer 3 and layer 4 of IP packets that are used for flow classification), QoS profile (worst case delay, delay jitter, average delay, throughput and accepted loss of packets), traffic profile (peak rate, average rate and burstiness), and price profile (price that user would pay as a function of data rate at which it is served). Information for multiple flows belonging to different applications can be conveyed in the same message. To differentiate these, the message header includes the number of applications for which data is enclosed in the message. Within the LMPSP_REQ message, an application id TLV (in type, length and value format) is used to differentiate among multiple applications. The Type of this TLV indicates to other node that this field contains the application id. Within data for each application, flow id TLV is used to differentiate among multiple flows belonging to the same application.
• LMPSP_ESTAB_DP_F: This message Is sent in the direction of forward link data flow from the WER to the PCF and/or from the PCF to the RN (to be specific, BSC in Figure 1). It carries some of the information needed to establish data path for flows on the WER-PCF and PCF-RN interfaces. Information for multiple fon/vard as well as reverse link flows is sent in the same message. Once data path has been established, these messages are sent to refresh or update state information (at PCF and RN, in the foHA^ard direction).

• LMPSP_ESTAB__DP_R: This message is sent from the PCF to the WER and also, from the RN (to be specific, BSC in Figure 1) to the PCF. It carries some of the information needed to establish data path for flows on the PCF-WER and RN-PCF interfaces. It also carries response for the LMPSP_ESTAB_DP_F message. Once data path has been established, these messages are sent to refresh or update state information (at PCF and WER, in the reverse direction).
• LMPSP_DP_REL: This message is sent from one node to another node to indicate that the application is being terminated and appropriate action should be taken to release the resources.
• LMPSP_RESP: This message is sent from the WER to the MS and contains response of the LMPSP_REQ message which was sent by the MS to the WER. It indicates whether or not all the required operations such as traffic management (schedulers, admission control and congestion management modules), pricing and flow classification operations were successful.
• LMPSP_UPDATE__REQ; This message is sent from one node to another node informing the other node about the updated information received.
Each protocol message uses a common header. This header includes the following:
- version number of the protocol
- message type (one of the above listed messages)
- message length (including the header length)
■ message checksum
- number of applications for which it is carrying data
■ source and destination IP addresses
After the above header, it contains information for each application. It includes a field which gives the number of flows for that application for which it is carrying data. For

1
r
each flow, it includes a direction indicator for indicating whether it is a fonA^ard link or a reverse link flow.
2. Networking System I
A novel networking system is described here, where the above LMPSP is used at the following nodes: MS, WER, PCF and RN (BSC to be specific). This is shown in Figure 6 and Figure 7, PCF could be part of WER or RN and is not shown explicitly in these figures here. It considers the case where the CN does not support RSVP. PPP session is established between the MS and the WER as described in Wireless IP Network Standard, www.3gDD2.org, 3GPP2 P.SOOOl-B.
The operation of this networking system is described for multimedia applications. Similar steps can be used for other applications. Consider the case where the MS has initiated a session level request (such as SIP Invite or RTSP setup request) to the CN. We describe operation of networking system I here. These are shown in Figure 8, Figure 9, Figure 10. Figure 11, Figure 12, and Figure 13.
1. The MS initiates a session level request (such as SIP invite or RTSP setup). This is shown in the Figure 10.
2. The CN responds back with a response message (such as SIP or RTSP response message) as shown in the Figure 10.
3. The MS upon receiving the response message from the CN, starts a timer, T_wait_QoS_Sig. The MS waits to receive a QoS signalling message from the CN. If the MS does not receive an explicit QoS signalling message from the CN before the expiry of this timer, it sends a LMPSP_REQ message to the CN. Here the case is considered when the CN does not support RSVP and thus in the figure shown below, the MS does not receive a QoS signalling message (RSVP here) from the CN. In this message, the MS sends traffic profile, QoS profile, flow classification and pricing information for multiple ' forward and reverse link flows to the WER. Note that these multiple flows can belong to the same application or different applications.

r
4. The WER processes information in the LI\/IPSP_REQ message and sends information for all the flows to the PCF to establish data path for these flows (as in Figure 10). For this purpose, the WER sends a LMPSP_ESTAB_DP_F message to the PCF.
- The WER and the PCF sets up traffic management components for forward
as well as reverse link flows. These components include: schedulers,
admission control modules and congestion management modules.
■ Flow classification module is also set up using information in this message.
- The WER assigns a unique number to each mobile to identify packets of that mobile on the WER-PCF interface. This mobile id is used locally by the WER and PCF. It further assigns application identifier and flow identifier for each flow for that mobile. It uses a GRE tunnel on the WER-PCF interface as in Wireless IP Network Standard, www.3gpp2.org. 3GPP2 P.SOOOl-B but structure of the GRE key is as shown in the Figure 8. Also, with this developed networking system, it is possible to carry GRE keys of multiple forwards as well as reverse link flows via the LMPSP messages on the WER-PCF interface. The WER assigns a unique GRE key for each reverse link flow that should be used by the PCF while sending data packet for that flow to the WER.
- The WER also creates a unique identifier, which is called temp_fljd, for each forward link flow and informs the PCF about it. The PCF later uses this when it informs the WER about the status of its requests for specific treatment for those flows. It is only temporarily used for flow identification purposes and not used once the data path is established. Packets corresponding to fonA^ard link data path use GRE key that is assigned by the PCF. This is shown in Figure 9.
Figure 9 shows a unique GRE key being assigned for each reverse link flow and a unique identifier for each forward link flow. This is marked as "A".
A unique GRE key is assigned for each fonA^ard link flow. Also the FL identifier assigned by the WER is used to inform WER about the response of its LMPSP_ESTAB_DP_F message. Use GRE key Assigned by the WER for reverse link Flows. This is marked as "B".

r
WER maps GRE keys for FL flows and identifiers it assigned earlier for FL flows.
GRE keys are only used in both the directions once the data path has been
established." This is marked as "C".
- After sending the LMPSP_ESTAB_DP_F message to the PCF, the WER also
starts a timer, T_F__WER. If the WER does not receive a response of this
message before the expiry of the timer, T_F_WER, it can retry sending the
LI\/IPSP_ESTAB_DP_F message certain number of pre-specified times. Upon
receiving a response of the LMPSP__ESTAB_DP_R message, it could also
decide to modify certain parts of the request before sending this message
again to the PCF,
5. The PCF upon receiving the LMPSP_ESTAB_DP_F message from the WER
(as in Figure 11), does the following:
■ It processes the message and checks to ensure that it can provide the
needed treatment to all the flows for which requests have been sent.
- It creates unique mobile identifier to be used for that mobile on the PCF-RN
interface. Note that this mobile id is of local significance only. It also assigns
application id and flow id for each flow in that message.
■ it allocates unique GRE keys for all the reverse link flows in that message.
This is the key that the PCF wants the RN to use while sending data packets
on the reverse link to the PCF. Again, structure of the GRE key is same as
that shown in the Figure 8.
- PCF sends a LMPSP_ESTAB_DP_F message to the RN using the above information.
- PCF also starts a timer, T_F_PCF, after sending the LMPSP_ESTAB_DP_F message to the RN. If the PCF does not receive response to its LMPSP_ESTAB_DP_F message before expiry of the T__F_PCF, it can resend this message to the RN a pre-specified number of times.
6. The RN upon receiving the LMPSP_ESTAB_DP_F message from the PCF
does the following:
- Creates a unique identifier for each reverse link flow. The MS has to use this
while sending data packets to the RN on reverse link. These identifiers for

v..
multiple flows are sent in the same message to the MS while doing channel establishment over the air.
Checks to see if traffic management modules (schedulers, admission control etc.) can support involved flows and applications.
- Performs channel establishment over the air with the MS following the
process as in Wireless IP Network Standard, www.3gpp2.org, 3GPP2
P.S0001-B but adds unique identifier for each reverse link flow.
7. Once the RN knows that channel establishment over the RN-MS interface
was successful, it sends a LMPSP_ESTAB_DP_R message to the PCF. This
is shown in the Figure 11. This message does the following:
■ It acts as response message to the LMPSP__ESTAB_DP_F message, which was sent by the PCF to the RN.
- The RN also creates unique GRE key for each fon/vard link flow and informs the PCF to use these while sending data in the forward direction for flows.
- This message does not contain flow classification information as that was already sent from the PCF to the RN. It uses GRE keys that were assigned by the PCF for reverse link flows to identify the reverse link flows and indicate result of data path establishment process for these reverse link flows. For fonward link flows, it uses the unique identifier that was assigned by the PCF for that flow, to inform the PCF about its response of the data path establishment request. The PCF maps this Identifier and the GRE key assigned by the RN for fonA^ard link flows and starts using only the GRE key once the data path establishment is successful.
8. The PCF upon receiving the LMPSP_ESTAB_DP_R message from the RN,
sends a LMPSP_ESTAB_DP_R message to the WER. This message acts as
response message to the LMPSP_ESTAB_DP_F message which was sent by
the WER to the PCF. The PCF also assigns unique GRE keys for each
foHA/ard link flow and informs the WER to use these while sending data
packets for forward link flow to the PCF. Again, keys of multiple flows to be
sent in the same message are allowed.

9. The WER receives the LMPSP_ESTAB__DP_R message from the PCF and sends a response message, LMPSP_RESP to the MS. This is shown in the Figure 12.
10. Upon receiving the LMPSP_RESP message, the IVIS can indicate to the CN to start sending the data. The MS can also start sending data for reverse link flows.
Once the MS or the CN decides to terminate the session, they exchange messages using the existing session level protocols such as SIP or RTSP. Upon receiving these terminating requests, the MS sends a LMPSP_REL message to the WER informing it to close sessions for these flows. Again, the LMPSP_REL messages are allowed to carry requests for multiple forward and reverse link flows at the same time. The WER in turn sends a LMPSP_REL message to the PCF which sends LMPSP___REL message to the RN. Each node which gets this message removes the state that was created earlier for these flows. This is shown in the Figure 13.
Simulation of A11 and A9 messages: Note that the messages corresponding to All and A9 are not explicitly sent as given in Wireless IP Network Standard, www.3gpp2.org, 3GPP2 P.SOOOl-B. In the present networking system, these messages are not necessary. If one wants to keep these messages for backward compatibility, one could still do so without sending All and A9 messages explicitly. They can be simply simulated within the same node when it receives or sends an appropriate LMPSP message.
3. Networking System II
In this networking system, consider a network where the CN supports RSVP. Like in networking system I, LMPSP is placed at the MS, WER, PCF and RN. PPP session is terminated at the MS and the WER. Refer to Figure 14 and Figure 15. Here, there are two cases to consider: First, when the CN's RSVP message arrives at the MS before the MS has sent the LMPSP_REQ message to the WER. Second, when the CN's RSVP message arrives at the MS after the MS has sent the LMPSP_REQ message to the WER.

Case 1
It describes operational details of this networking system for the case where the RSVP Path message arrives at the MS before the MS has initiated the LMPSP_REQ message. These details are shown in Figure 16, Figure 17, Figure 18, Figure 19, Figure 20 and Figure 21.
1. The MS receives a SIP (or RTSP) response message from the CN (as shown in the Figure 16). It starts a timer, T_Walt_QoS„Sig. in the meantime, the CN sends an RSVP Path message towards the MS. The WER processes this Path message and sends an RSVP Path message to the MS. In Case I here, the MS receives the RSVP Path message before the expiry of the timer, T_Wait_QoS„Sig.
2. The MS uses this information and the information received via session level protocols (such as SIP, RTSP etc.) to create the LMPSP_REQ message. The MS is allowed to dynamically aggregate RSVP requests of multiple flows into one LMPSP_REQ message. There is a timer, T_Agg_MS, for this purpose. If the MS receives multiple requests during this period, it is allowed to aggregate those requests in the same LMPSP message.
3. As shown in the Figure 16, the MS sends LMPSP^REQ message to the WER. As described earlier, this message contains information for multiple foHA/ard and reverse link flows.
4. After these steps, the data path establishment steps are similar to the steps described in the networking system I. These are shown in Figure 17.
5. Once the data path has been established, the WER sends the LMPSP_RESP message to the MS as shown in Figure 18.
6. In the networking system here, the MS and the WER do not explicitly exchange RSVP messages to refresh their signalling state blocks. Instead, these are simulated internally at the MS and the WER as shown in Figure 18. These RSVP state blocks are not removed until LMPSP_REL message is received or the lifetime timers associated with these RSVP state blocks timeout. Other data flow details have been also shown In Figure 18.
7. Once the MS and the CN decide to close a session, the MS sends an LMPSP_REL message as shown in Figure 19. The MS also removes LMPSP

and RSVP state blocks associated with the flows for which the session Is being terminated. 8. Other nodes (i.e. WER, PCF and RN) also remove state blocks associated with these flows.
As RSVP Path message is sent per-flow only, it allow the MS to aggregate multiple RSVP Path requests (and associated SIP/RTSP requests) into the same LMPSP_REQ message using the dynamic aggregation feature of LMPSP. This is shown in Figure 20. WER doesn't remove the RSVP path state block until it receives the LMPSP_REL message RSVP path refresh is simulated locally at the WER. The MS is allowed to aggregate multiple RSVP path requests into one LMPSP_REQ message. The WER is allowed to aggregate responses for multiple flows into one LMPSP_RESP message.
For reverse link flows, the MS initiates request via the LMPSP_REQ message, as described earlier. Once the WER receives this message, it may need to send RSVP messages towards the CN as the ON also supports RSVP in the network considered here. In this case, an LMPSP-RSVP proxy is placed at the WER. This proxy converts the LMPSP messages to the corresponding RSVP messages (and vice verse). Thus this proxy may generate multiple RSVP Path messages as a result of one LMPSP_REQ message and may aggregate RSVP Resv messages corresponding to multiple flows into one LMPSP_UPDATE_REQ message. This update message is sent from the WER to the MS, as shown in Figure 21, and informs the MS about the updates received from the CN.
Case II
Consider the case where the MS has sent the LMPSP_REQ message to the WER and then the MS receives an RSVP Path request from the CN. In this case, some of the data path establishment steps may have already been completed (or may be in progress). On receiving the RSVP Path message, the MS checks to see if some information needs to be changed and if needed, it informs the WER about this via an LMPSP_UPDATE_REQ message. The WER informs the PCF about this new piece

information, wliich in turn conveys it to the RN. Refer to Figure 22 and Figure 23. Other steps involved are similar to those described in Case I above.
4- Networking System III
In this networking system, PPP session between the MS and the RN is created. Thus, it terminates PPP at the RN instead of the WER as done in the earlier networking systems. It allows us to decouple functionality of the RN and the WER to a greater extent and provide greater flexibility in designing and managing networks. LMPSP is used at the MS, RN, PCF and WER. A network where the CN does not support RSVP is considered. Operational details are shown in Figure 24, Figure 25, Figure 26 and Figure 27, and described below :
1. PPP session is established between the MS and the RN only. Thus PPP is terminated at the RN.
2. The MS initiates LMPSP_REQ as shown in Figure 24, which is terminated at the RN.
3. The RN initiates the data path establishment over the MS-RN and the RN-PCF interface. The RN creates unique identifiers for each reverse link flow and asks the MS to use those while sending data packets for those flows on the reverse link. The RN also creates unique GRE key for each fonA^ard link flow and a unique identifier for each reverse link flow and informs these to the PCF via the LMPSP_ESTAB_DP_R message. It also conveys information that is used for flow classification, QoS management and pricing related decisions.
4. The PCF on receiving the LMPSP_ESTAB_DP_R message from the RN, creates unique GRE key for each forward link flow and unique identifier for each reverse link flow and informs about these to the WER via the LMPSP__ESTAB_DP___R message. These steps are shown in the Figure 24.
5. Upon receiving the LMPSP_ESTAB_DP_R message from the PCF, the WER processes it for traffic management, flow classification and pricing purposes. It also creates unique GRE key for each reverse link flow and informs the PCF about these by sending an LMPSP_ESTAB_DP_F message to the PCF. The WER also sends the unique identifiers that it has received for these flows from the PCF to allow the PCF to associate the GRE key created by the WER and

the unique identifiers created by PCF for reverse link flows. To inform the PCF about the forward link flows, it uses the GRE keys that were assigned by the PCF for these fonA^ard link flows. These steps are shown in Figure 25 and Figure 27.
Here a unique GRE key is assigned for each fonA/ard link flow and a unique identifier for each reverse link flow. This is marked as "A" in the Figure 27.
A unique GRE key is assigned for each reverse link flow. Also the RL identifier assigned by the RN is used to inform RN about the response of its LMPSP_ESTAB_DP__R message GRE key Assigned by the RN is used for fonA/ard link Flows. This is marked as "B" in the Figure 27.
RN maps GRE keys for RL flows and identifiers it assigned earlier for RL flows. Only GRE keys is used in both the directions once the data path has been established. This is marked as " C" in the Figure 27.
6. The RN sends a response message, LMPSP_RESP, once it finds out that data path has been established properly. Now, the CN and the MS start exchanging data for their flows.
7. Once the MS (or the CN) decides to close the application session, it sends an LMPSP_REL message to the RN, as shown in Figure 26 and removes LMPSP state associated with the flows for which the LMPSP_REL was initiated,
5, Networking System IV
Here a network where the CN also supports RSVP is considered. As in networking system III, it establishes PPP session only between the MS and the RN. LMPSP is used at MS, RN, PCF and WER.
Case I
Operational details are shown in Figure 28, Figure 29, Figure 30 and Figure 31. These are described below:

1. The CN generates an RSVP Path message and sends it to the WER as shown in the Figure 28.
2. Here, one could use RSVP or LMPSP messages at the WER and the PCF. We describe the case where LIVIPSP is used at these nodes. The WER generates an LIVIPSP_UPDATE_REQ and sends it to the PCF which in turn conveys it to the RN. Finally, the MS is also informed about this. In case I here, this LMPSP_UPDATE_REQ reaches the MS before it has created an LMPSP^REQ message.
3. The MS can wait for some time at this stage and wait to see if it can aggregate multiple RSVP requests (and impact of SIP/RTSP protocol messages) into one request.
4. The MS generates LMPSP_REQ message and sends it to the RN.
5. Other operations details are shown in Figure 29, Figure 30 and Figure 31.
Case II
In this case, the MS receives an LMPSP_UPDATE_REQ message from the RN after the MS has already sent the LMPSP_REQ message to the RN. In such a case, it is possible that the RN, PCF and WER have already started doing data path establishment. In such a case, the MS can send an LMPSP_UPDATE_REQ message to the RN about updated information. The RN would in turn inform the PCF about this updated information. These steps are shown in Figure 32, Figure 33 and Figure 34.
While the invention has been particularly described with reference to preferred embodiments, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.

GLOSSARY OF TERMS AND THEIR DEFINITIONS
3G: Third Generation wireless networks. These networks are to provide next
generation mobile services with better quality of service and high speed Internet and
multimedia services. These include networks such as CDMA2000 1xEV-D0,
CDMA2000 1xEV-DV, WCDMA.
BTS: Base Transceiver System. The air interface in 3G wireless networks terminates
at the BTS and the mobile station.
BSC: Base Station Controller
CDMA: Code Division Multiple Access. It is a spread-spectrum technology allowing
many users to occupy the same time and frequency allocations in a given
band/space. It assigns unique codes to each communication to differentiate it from
others in the same spectrum.
CDMA2000 1xEV: This includes CDMA2000 IxEV-DO and CDMA2000 1xEV-DV.
CDMA2000 1xEV-D0: CDMA2000 Single Carrier Evolution, Data Optimized. It
delivers peak data rates of 2.4 Mbps and is intended to provide high performance
and low cost packet data services.
CDMA2000 1xEV-DV: CDMA2000, Single Carrier, Evolution, Data and Voice. It
provides integrated voice and simultaneous high-speed packet data multimedia
services.
Correspondent Node (CN): It is a node with which the MS is communicating. For
example, it could be a multimedia server or some other mobile station.
Forward link flows: These flows are sending data packets from CN (or WER)
towards the MS.
FTP: File Transfer Protocol. A widely used protocol in the internet used to transfer
files from one point to another point.
HTTP: Hyper-Text Transfer Protocol. A protocol widely used for web browsing
applications in the internet.
IP: Internet Protocol. A layer 3 protocol widely used in the internet.
LCP: Link Control Protocol. It is used to negotiate radio link protocol and options to
control the session in CDMA2000 wireless networks.
MPEG: Moving Picture Experts Group. There are several MPEG standards such as
MPEG-4, MPEG-2 etc.
MS: Mobile Station

NACK: Negative Acknowledgement. In contrast to positive acknowledgements,
NACK is typically sent when a packet is not received within some expected time
interval.
QoS (Quality of Service): Applications have different types of requirements and
these should be met by the networks. These include delay bound, delay jitter,
required rate, packet loss, and average delay.
Reverse link flows: These flows are sending data from the MS towards the CN (or
WER).
RLP: Radio Link Protocol. It is a modified form of the automatic repeat request
(ARQ) protocol and used in 3G networks to improve reliability of the air-interface.
RN: Radio network consisting of BSC and BTS. We use it interchangeably with BS
(base station).
RSVP: Resource Reservation Protocol. It is a QoS signaling protocol specified in the
RFC2205 and available at www.ietf.org
RTSP: Real Time Streaming Protocol. This is used to establish session for
streaming applications in internet.
SCP: Stream Control Protocol. This is used for sending RLP negative
acknowledgements in CDMA2000 networks when missing RLP data is detected.
SIP: Session Initiation Protocol. This session level protocol is used to establish
sessions for streaming/conferencing applications in Internet.
TCP: Transport Control Protocol. A layer 4 protocol widely used in the internet.
VoIP: Voice over IP
WCDMA: Wideband Code Division Multiple Access
WER: Wireless Edge Router

WE CLAIM
1. An efficient IP networking system for 3G wireless multimedia networks managing QoS, comprising liglitweight multipurpose signaling protocol (LMPSP); means for Flow classification, QoS management and Dynamic price management for wireless networks; means for Flow Differentiation and Aggregation, means for sending a single message that includes information about all forward as well as reverse flows, and means for assigning different application identifiers to multiple applications running on a mobile.
2. A networking system as claimed in claim 1, wherein when the Correspondent Node (CN) does not support RSVP, PPP endpoints are at the Mobile Station (MS) and the Wireless Edge Router (WER), in that LMPSP is kept at the WER, Packet Control Function (PCF), BS and MS.
3. A networking system as claimed in claim 1, wherein when the CN supports RSVP, LMPSP is kept at the MS, WER, PCF and RN and PPP session is terminated at the MS and the WER.
4. A networking system as claimed in claim 1, wherein PPP session is between the MS and the RN, LMPSP is kept at the MS, RN, PCF and WER and the CN does not support RSVP.
5. A networking system as claimed in claim 1, wherein the CN also supports RSVP; PPP session is only between the MS and the RN and LMPSP is used at MS, RN, PCF and WER.
6. A method for efficiently implementing quality of service (QoS) for an internet protocol (IP) network, said method comprising the steps of providing a Lightweight Multipurpose Signaling Protocol (LMPSP) for wireless networks to efficiently carry out the following functions namely, flow classification, QoS management, and dynamic price management for wireless networks; sending one message that includes information about all forward as well as reverse flows; carrying out Flow Differentiation and Aggregation in that the MS conveys information to the WER and

r the BS regarding combining some flows for the purpose of QoS management;
multiple applications running on a mobile are assigned different application Identifiers
and LMPSP protocol packets are carried using UDP or raw IP datagrams.
7. A method for efficiently implementing quality of service (QoS) for an internet protocol (IP) network as claimed in claim 6, wherein in addition to managing QoS in wireless networks, for end-to-end QoS management in a network, a LMPSP-RSVP proxy isplaced at the WER which allows LMPSP and RSVP to exist together in a network and converts the LMPSP messages to the corresponding RSVP messages and vice verse and further this proxy generates multiple RSVP Path messages as a result of one LMPSP_REQ message and aggregates RSVP Resv messages corresponding to multiple flows into one LMPSP_UPDATE_REQ message.
8. A method as claimed in claim 6, wherein a networking system is provided where when the Correspondent Node (CN) does not support RSVP, PPP endpoints are at the Mobile Station (MS) and the Wireless Edge Router (WER), in that LMPSP is kept at the WER, Packet Control Function (PCF), BS and MS.
9. A method as claimed in claim 6 comprising the following detailed steps of :

a) MS initiates a session level request;
b) The CN responds back with a response message;
c) MS upon receiving the response message from the CN, starts a timer, and sends a LMPSP_REQ message to the CN;
d) The MS sends traffic profile, QoS profile, flow classification and pricing information for multiple forward and reverse link flows to the WER;
e) The WER processes information in the LMPSP_REQ message and sends information for all the flows using LMPSP_ESTAB_DP_F message to the PCF to establish data path for these flows and the WER also starts a timer, T.F_WER;
f) The WER and the PCF set up traffic management components viz. schedulers; admission control, flow classification and congestion management modules forfonA/ard as well as reverse link flows;

g) The WER assigns a unique number to each mobile to identify packets of that
mobile on the WER-PCF interface and further assigns application identifier
and flow identifier for each flow for that mobile; h) The WER assigns a unique GRE key for each reverse link flow that should be
used by the PCF while sending data packet for that flow to the WER; i) The WER also creates a unique identifier, for each forward link flow and
informs the PCF about it. And after sending the LMPSP_ESTAB_DP__F
message to the PCF; j) The PCF upon receiving the LMPSP_ESTAB_DP_F message from the WER,
processes it and sends it to RN; k) The RN upon receiving the LMPSP_ESTAB_DP_F message from the PCF
processes it and once the channel establishment over the RN-MS interface
was successful, it sends a LMPSP_ESTAB__DP_R message to the PCF; I) The PCF upon receiving the LMPSP_ESTAB_DP_R message from the RN,
sends a LMPSP__ESTAB_DP_R message to the WER; m) The WER on receiving the LMPSP_ESTAB_DP_R message from the PCF
sends a response message, LMPSP_RESP to the MS; n) Upon receiving the LMPSP_RESP message, the MS indicates to the CN to
start sending the data. And MS can also start sending data for reverse link
flows.
10, A method as claimed in claim 9, wherein for backward compatibility A11 and A9
messages are simulated within the same node when it receives or sends an
appropriate LMPSP message.
11. A method as claimed in claim 6, wherein to decouple functionality of the RN and
the WER to a greater extent and provide greater flexibility in designing and
managing networks where the CN does not support RSVP the following steps are
carried out:
a) The MS initiates LMPSP_REQ which is terminated at the RN;
b) The RN initiates the data path establishment over the MS-RN and the RN-PCF interface;
c) The RN creates unique identifiers for each reverse link flow and requests the MS to use those while sending data packets for those flows on the reverse

>
link and also creates unique GRE key for each fonA/ard link flow and a unique identifier for each reverse link flow and send the information to the PCF via the LMPSP_ESTAB_DP_R message;
d) RN also conveys information that is used for flow classification, QoS management and pricing related decisions;
e) The PCF on receiving the LMPSP_ESTAB_DP_R message from the RN, creates unique GRE key for each fonA/ard link flow and unique identifier for each reverse link flow and informs the WER via the LMPSP„ESTAB_DP_R message;
f) The WER processes the LMPSP_ESTAB_DP_R message from the PCF for traffic management, flow classification and pricing purposes and also creates unique GRE key for each reverse link flow and informs the PCF by sending an LMPSP_ESTAB_DP_F message to the PCF;
g) The WER also sends the unique identifiers received for these flows from the PCF to allow the PCF to associate the GRE key created by the WER and the unique identifiers created by PCF for reverse link flows;
h) using the GRE keys that were assigned by the PCF for these fon/vard link
flows it informs the PCF about the forward link flows; i) The RN sends a response message, LMPSP_RESP once the data path has
been established properly and the CN and the MS start exchanging data for
their flows.
12. A method as claimed in claim 6, wherein the CN also supports RSVP and the following steps are carried out:
a) The CN generates an RSVP Path message and sends it to the WER;
b) LMPSP is used at the nodes and the WER generates an LMPSP_UPDATE_REQ and sends it to the PCF which in turn conveys it to the RN and finally to MS;
c) The MS waits for some time at this stage to decide if it can aggregate multiple RSVP requests and impact of SIP/RTSP protocol messages) into one request. And then generates LMPSP_REQ message and sends it to the RN.

13. A method as claimed in claim 6, wherein a networking system is provided where
CN does not supports RSVP; PPP session is established between the MS and the
RN only and LMPSP is used at the MS, RN, PCF and WER.
14. A method as claimed in claim 6, wherein when the CN supports RSVP, LMPSP
is kept at the MS, WER, PCF and RN and wherein PPP session is terminated at the
MS and the WER.
15. A method as claimed in claim 6, wherein a networking system is provided where
the CN also supports RSVP. PPP session is only between the MS and the RN and
LMPSP is used at MS, RN, PCF and WER in that WER and the RN are decoupled to
a greater extent.
16. An efficient IP Networking System for 3G wireless multimedia networks
substantially as herein described particularly with reference to the drawings.
17. The efficient methods for IP Networking for 3G Wireless Multimedia Networking
systems substantially as herein described particularly with reference to the drawings.

Documents:

888-che-2003-abstract.pdf

888-che-2003-claims duplicate.pdf

888-che-2003-claims original.pdf

888-che-2003-correspondence others.pdf

888-che-2003-correspondence po.pdf

888-che-2003-description complete duplicate.pdf

888-che-2003-description complete original.pdf

888-che-2003-drawings.pdf

888-che-2003-form 1.pdf

888-che-2003-form 13.pdf

888-che-2003-form 26.pdf

« Previous Patent

Next Patent »

Patent Number

201066

Indian Patent Application Number

888/CHE/2003

PG Journal Number

08/2007

Publication Date

23-Feb-2007

Grant Date

27-Jun-2006

Date of Filing

03-Nov-2003

Name of Patentee

M/S. SAMSUNG ELECTRONICS CO. LTD.,

Applicant Address

SOFTWARE OPERATIONS (SISO) SAMSUNG ELECTRONICS COMPANY LIMITED, J.P. TECHNO PARK, 3/1, MILLERS ROAD, BANGALORE 560 052, KARNATAKA, INDIA

Inventors:

#	Inventor's Name	Inventor's Address
1	TANEJA, MUKESH	EMPLOYED AT SANSUNG ELECTRONICS CO. LTD., SOFTWARE OPERATIONS (SISO) SAMSUNG ELECTRONICS COMPANY LIMITED, J.P. TECHNO PARK, 3/1, MILLERS ROAD, BANGALORE 560 052, KARNATAKA, INDIA

PCT International Classification Number

G08B25/10

PCT International Application Number

N/A

PCT International Filing date

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1			NA