HK1085063A - Packet flow processing in a communication system - Google Patents

Description

Packet stream processing in a communication system

Priority requirements under 35U.S.C. § 120

This patent application claims priority from a patent application having patent application number 10/170059, entitled "PACKET FLOW PROCESSING IN a COMMUNICATION SYSTEM," filed on 10/7/2002, which is assigned to the assignee of the present invention and is expressly incorporated herein by reference.

Background

FIELD

The present invention relates to packet flow processing in a communication system, and more particularly to packet flow mapping and processing in a communication system having Internet Protocol (IP) components to support the processing of multiple service instances.

Background

Communication systems that support data communication typically include Internet Protocol (IP) components or portions in which data is communicated in an IP format. Likewise, the communication system may communicate with an IP system or participate in the communication of IP nodes. For such communications, data is transmitted in packets; a series of packets is called a "packet stream". To process a packet stream, certain information is required by the infrastructure elements of the communication system. For example, the infrastructure element may require header compression and/or mapping information so that the infrastructure element can direct the packet flow to the appropriate link layer connection.

There is therefore a need in the art to provide packet flow information to infrastructure elements that require such information. Also, there is a need for an efficient method for mapping and processing packet flows in a communication system.

Brief description of the drawings

Fig. 1 is a communication system.

Fig. 2 is a call flow of a process in which the PDSN determines flow processing and the mapping of packet flows from RSVP messages.

Fig. 3 is a call flow of a process in which a PDSN determines flow processing and mapping from a "sniffing" Session Initiation Protocol (SIP) message.

Fig. 4 illustrates a communication system supporting a source reservation protocol.

Fig. 5 is a mobile station adapted to process a packet stream.

Fig. 6-8 illustrate packet stream processing in accordance with various embodiments.

Fig. 9 is a multi-channel streaming protocol (MCFTP) packet format.

Description of The Preferred Embodiment

The phrase "exemplary" is used herein to mean "serving as an example, instance, or illustration. Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

Fig. 1 is a communication system 100 suitable for data communication. Communication system 100 includes a Mobile Station (MS)102 in communication with a Base Station (BS) 104. The BS104 also communicates with a Packet Data Serving Node (PDSN)106, as well as with other components that handle voice communications, etc. (not shown). PDSN106 serves as an interface for MS102 and BS104 to a data network, such as a network supporting IP communications.

The MS102 supports data communications, of which several a10 connections and Service Option (SO) connections are illustrated. The SO connection is used for communication of selected service options, such as packet data services. In turn, the a10 connection provides a link for sending Internet Protocol (IP) packets between the PDSN106 and the BS 104. The SO connection provides a link for sending IP packets between the MS102 and the BS 104. There is a one-to-one mapping between the SO connection (MS-BS) and the a10 connection (BS-PDSN). Multiple a10/SO connection pairs are shown in fig. 1 because MS102 supports multiple simultaneous connections. In other words, MS102 is capable of processing multiple packet flows in parallel. Each packet flow is assigned to an a10 connection or link. The assignment of a packet flow to the a10 link is referred to as the packet flow "map" and is determined by the PDSN. There are a number of standards and algorithms for such mapping that may be applied in the system 100 of fig. 1.

As discussed above, each SO connection or link between the MS102 and the BS104 has a corresponding a10 connection or link between the BS104 and the PDSN 106. This correspondence is shown by the dashed line of the BS 104. The SO/a10 connection may be used for two-way or interactive communications, such as voice over IP (VoIP) communications, or may be used for one-way communications, such as downloading data, or for streaming information from an internet source. As the number of data communication types increases, SO/a10 connections may be implemented for more and more of these communications. Notably, multiple SO connections (a.k.a. service instances) are required to support different QoS requirements of packet flows. For example, MS102 may have two active SO connections. The first SO connection, having a retransmission mechanism to provide reliable over-the-air delivery at the expense of transmission delay, is therefore used to deliver data requiring reliable transmission. The second SO connection may not have a retransmission mechanism and is used to transmit data that requires a rush transmission.

PDSN106 also includes an Authentication Accounting and Authorization (AAA) 112. AAA112 serves to authenticate connections and track billing finances, etc. through the carrier or service provider. PDSN106 receives packet streams from Correspondent Node (CN)108 and from other sources 110. The CN108 may be a node, service provider, terminal, etc. on the internet. In other words, the CN108 is a source of information or a participant in a communication. Notably, PDSN106 may receive multiple packet flows from multiple sources, where the packet flows are destined for multiple participants, such as MS 102. Each packet flow is mapped to a corresponding SO/a10 connection and processed according to the parameters negotiated by the participants.

Flow mapping and handling of each packet flow is particularly important when multiple service instances are established to a given user, such as MS 102. If MS102 has multiple active service instances and MS102 uses multiple header compression algorithms, PDSN106 will expect information for handling the packet flows associated with each service instance. The information includes, but is not limited to, a specific header compression algorithm for each packet flow, and a mapping of each packet flow to each a10 connection.

The embodiment described herein below is a method of providing flow processing information via RSVP messages that contain a new object called flow processing. RSVP messages are a resource reservation setup Protocol designed for integrated services on the internet, and are described in RFC2205, entitled "resource Reservationprotocol (RSVP)" by RFC2205, r. The RSVP protocol is used by hosts to request a particular quality of service from the network for certain application data flows. RSVP is also used by routers to deliver quality of service (QoS) to all nodes along a path along the flow, as well as to establish and maintain state to provide requested services. RSVP requests typically result in the source being retained within each node along the data path. RSVP messages provide packet filters for bi-directional packet flows (e.g., interactive VoIP sessions) or unidirectional packet flows (e.g., streaming sessions). Packet filters are used by nodes to identify a certain packet flow.

RSVP defines a "session" as a data flow having a certain destination and transport layer protocol. RSVP handles each session independently. The RSVP session is defined by a triplet: (DestAddress, protocol Id [ DstPort ]). Here DestAddress, the IP target address of the data packet, may be a unicast or multicast address. Protocol ID is IP protocol ID. The optional DstPort parameter is the "generalized destination port", i.e. the point at which some further demultiplexing occurs in the transport or application protocol layer. DstPort can be defined by a user Datagram protocol/Transmission control protocol (UDP/TCP) destination port field, by an equivalent field in another transport protocol, or by some application specific information.

After establishing a primary service instance, when the MS102 decides to establish a secondary service instance, the MS102 sends RSVP PATH and RESV messages to request quality of service (QoS) resources. In the RSVP RESV message, MS102 will characterize the data flow by IP address and port number and pass the codec type and header compression type. Upon receiving the RSVP RESV message, the PDSN will check the information and request a new a10 connection to the BS and associate the newly established a10 connection with a packet flow characterized by the filter specification and optionally by the session level (defined below with respect to the RSVP type protocol). Fig. 4 details the format of an RSVP message consistent with RFC 2205. RSVP messages are considered as an example of messages that may be used for packet flow processing and/or information transfer required by the mapped PDSN. Alternate embodiments may implement other messages to provide the same or similar information.

It is noted that throughout the discussion of RSVP-type protocols, directional terms are defined in terms of the direction of data flow. The RSVP message carrying the reservation request starts at the receiver and goes upstream to the sender. In particular, the directional terms "upstream" relative to "downstream", "previous hop" relative to "next hop", and "ingress interface" relative to "egress interface" are defined relative to the direction of data flow.

Fig. 4 illustrates a communication system having a host 401 and a router 450, the router 450 implementing the RSVP protocol. As illustrated, host 401 includes an application unit 404 bi-directionally coupled to RSVP processing unit 404. The RSVP processing unit determines the appropriate RSVP messages and content for transmission and also considers those RSVP messages and content received from router 450. RSVP processing unit 404 is coupled to policy control unit 506. Communication within host 401 is through communication bus 420. The host 401 also includes an admission control unit 408, a packet scheduler 410, and a classifier 412.

Continuing with fig. 4, router 450 includes similar elements as in host 401, however this configuration may be implemented in a slightly different manner. Router 450 includes router unit 452, RSVP processing unit 454, policy control unit 456, admission control unit 458, packet scheduler 460, and classifier 462, all of which communicate via communication bus 480. Notably, RSVP processing unit 404 communicates RSVP messages to and from RSVP processing unit 454.

Within system 400, quality of service is achieved for a data flow through mechanisms collectively referred to as "traffic control. These mechanisms include (1) a packet classifier (classifier 412, 462), (2) an admission control (admission control 408, 458), and (3) a "packet scheduler" (packet scheduler 410, 460) or some other link layer related mechanism to determine when to forward certain packets. The "packet classifier" mechanism or classifier 412, 462 determines the QoS class (and perhaps route) of each packet. For each egress interface, a "packet scheduler" or other link-layer related mechanism achieves the promised QoS. Traffic control implements a QoS service model defined by integration.

During reservation setup, the RSVP QoS request is passed to two local decision modules, "admission control" (admission control 408, 458) and "policy control" (406, 456). The admission control 408, 458 determines whether the node has sufficient available resources to provide the requested QoS. Policy control (406, 456) determines whether the user has administrative permission to make the reservation. If both checks succeed, parameters are set in the packet classifier and in the link layer interface (e.g., in the packet scheduler) to achieve the desired QoS. If either check fails, the RSVP program returns an error notification to the application process that originated the request.

The RSVP protocol mechanism provides for creating and maintaining distributed reservation state on a mesh of multicast or unicast delivery paths. The RSVP itself passes the QoS and policy control parameters to the appropriate traffic control and policy control modules for interpretation, in accordance with the opaque data passing and operating them. Since the membership of large multicast groups and the resulting multicast tree topology may change over time, the RSVP design assumes that the state of RSVP and traffic control states will be gradually established and destroyed in routers and hosts. For this purpose, RSVP establishes a "soft" state; i.e., RSVP sends periodic update messages to maintain state along the saved path. In the absence of update messages, the status automatically expires and is deleted. In summary, RSVP has the following attributes:

RSVP makes resource reservations for unicast and many-to-many multicast applications, dynamically adapting to changing group membership and changing routes.

RSVP is simplex, i.e., supports reservation of unidirectional data flows.

RSVP is receiver oriented, i.e. the receiver of a data flow initiates and maintains resource reservation for said flow.

RSVP maintains "soft" state in routers and hosts, providing good support for dynamic membership changes and adaptive routing changes.

RSVP is not a routing protocol, but supports present and future routing protocols.

RSVP transport and maintenance traffic control and policy control parameters that are opaque to RSVP.

RSVP provides several reservation models to accommodate a variety of applications.

RSVP provides transparent operation through RSVP-incapable routers.

RSVP supports IPv4 and IPv 6.

An exemplary RSVP reservation request consists of "flow specification" and "filter specification" together; this pair is called a "stream descriptor". The flow specification specifies the desired QoS. The filter specification and the session specification together define a set of data packets-the "flow" -to receive the QoS defined by the flow specification. Flow specifications are used to set parameters in the node's packet scheduler or other link layer mechanism, while filter specifications are used to set parameters in the packet classifier. Data packets addressed to a session but that do not match any filter specifications for that session are processed as best effort traffic.

The flow specification in the reservation request typically includes a service level and two sets of numerical parameters: (1) "Rspec" (R stands for "reserved") that defines the desired QoS, and (2) the "Tspec" (T stands for "traffic") that describes the data flow. The format and content of Tspec and Rspec are determined by the system and are generally opaque to RSVP.

The exact format of the filter specification depends on which IP version is used. The current version considers either IPv4 or IPv 6. According to one approach, the filter specification may select any subset of packets in a given session. These subsets may be defined in terms of the sender (i.e., the address of the sender and the unified source port), in terms of higher layer protocols, or generally in terms of fields within any protocol header in the packet. For example, a filter specification may be used to select different sub-streams of a layered coded video stream by selecting on a field of an application layer header. For simplicity (and to minimize layer violations), the basic filter specification format defined in the current RSVP specification has a very strict form: sender IP address and optional UDP/TCP port number SrcPort.

At each intermediate node, the reservation request triggers two general operations, as follows:

1. reservation on the link:

the RSVP process passes requests for admission control and policy control. If any of the tests fail, the reservation is popped and the RSVP process returns an error message to the appropriate receiver. If both are successful, the node sets the packet classifier to select the data packet defined by the filter specification and it interacts with the appropriate link layer to obtain the desired QoS defined by the flow specification.

The detailed rules for satisfying RSVP QoS requests depend on the particular link layer technology used at each layer. For example, for a simple leased line, the desired QoS would be obtained from the packet scheduler within the link layer driver. If the link layer technology implements its own QoS management capabilities, then RSVP negotiates with the link layer to obtain the requested QoS. Notably, the operation of controlling QoS occurs at the point of entry of data into the link layer medium, i.e., at the upstream end of the logical or physical link, despite the RSVP reservation request originating downstream from the receiver.

2. Forwarding the request upstream:

the reservation request is propagated upstream towards the appropriate sender. The set of sender hosts to which a given reservation request is propagated is referred to as the "scope" for that request.

A node forwards a reservation request upstream differently than a request received from downstream for two reasons. The traffic control mechanism may modify the flow specification hop-by-hop. More importantly, the different downstream flow branch reservations from the multicast tree from the same sender (or set of senders) must be "fused" as the reservations are transported upstream.

When the receiver initiates a reservation request, it can also request an acknowledgement message to indicate that its request is (possibly) installed in the network. A successful reservation request propagates upstream along the multicast tree until it reaches a point where there is a reservation equal to or greater than the reservation being requested. At this point, the arriving request is merged with the in-place reservation and does not need to be forwarded further; the node may then send a reservation confirmation message back to the receiver.

There are two basic RSVP message types: RESV and PATH. Each receiver host sends an RSVP reservation Request (RESV) message upstream to the sender. These messages must travel upstream to all sender hosts included in the sender selection, just along the reverse of the path that the data packet will take. The RESV message results in the establishment and maintenance of a "reservation state" within each node along the path. The RESV message is finally passed to the sender hosts themselves so that these hosts can establish the appropriate traffic control parameters for the first hop along the path.

Each RSVP sender host sends an RSVP "PATH" message downstream along the PATH of the data along a single/multicast route provided by the routing protocol. These RSVP PATH messages store the "PATH state" within each node in this direction. This path state comprises at least the IP address of the previous hop node, which is used to route RESV messages hop-by-hop in the reverse direction. It is noted that future designs may implement routing protocols that directly provide a reverse path for forwarding information, replacing the reverse routing function of the path state.

The PATH message also contains the following information in addition to the previous hop address:

1. sender template

The PATH message is required to transmit a sender template that describes the format of the data packet that the sender will originate from. This template is in the form of a filter specification that can be used to select the sender's packets from others in the same session on the same link. The sender template has exactly the same representation power and format as the filter specification present in the Resv message. Thus, the sender template may specify only the sender IP address and optionally the UDP/TCP sender port, and use the protocol Id specified for this session.

2. Sender Tspec

The PATH message is required to transmit a sender Tspec defining the traffic characteristics of the data stream that the sender will generate. This Tspec is used by traffic control to prevent over-reservation and may not necessarily allow control to fail.

3.Adspec

The path message may transmit packets of OPWA advertisement information, which is referred to as "Adspec". The Adspec received in the PATH message is transmitted to the local telephone traffic control, and the local telephone traffic control returns an updated Adspec; the updated version is then forwarded in a PATH message sent downstream. The PATH messages are sent as data with the same source and destination addresses so that they will be routed correctly through the non-RSVP cloud. On the other hand, the RESV message is sent hop-by-hop; each RSVP speaking node forwards a RESV message to the unicast address of the previous RSVP hop.

Fig. 2 illustrates two-way interactive call processing between MS102, BS104 (including Packet Control Function (PCF) operations), PDSN106, AAA108, and CN 110. This flow is described chronologically in steps labeled 1 through 16.

At step 1, the MS establishes a Service Option (SO), such as a packet data service SO33, before the mobile station can send application triggered Session Initiation Protocol (SIP) signaling. In the illustrated example, Radio Link Protocol (RLP) retransmission is enabled. This provides a mechanism by which SIP messages are reliably propagated over the air. Notably, SIP is published by the internet engineering task force, j.rosenberg et al, under the literature reference draft-ietf-SIP-rfc2543bis-08.ps, "SIP: session Initiation Protocol "is described in detail; and also by m.handley et al, published by the network working group, with document number RFC2543, with a date of 3 months 1999, "SIP: session Initiation Protocol "is also described in detail.

Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for establishing, modifying, and terminating sessions with one or more participants. These sessions include internet telephone calls, multimedia distribution, and multimedia conferences. The SIP invite to establish the session carries a session description that allows participants to agree on a set of consistent media types. SIP uses elements called proxy servers to facilitate routing requests to the user's current location, authenticate and authorize the user for services, implement provider call-routing policies, and provide features to the user. SIP also provides registration functions that allow users to upload the current location they use through a proxy server. SIP operates on top of several different transport protocols.

In step 2, the MS establishes a point-to-point (PPP) session with the PDSN. This provides a bearer connection for the link layer so that a connection for the packet flow is established. It is noted that PPP is described in detail in "The Point-to-Point protocol (PPP)", authored by W.Simpson, published by The network working group as RFC1661, and dated 7 of 1994.

In step 3, the PDSN sends an access request to the AAA, which contains the MS Network Access Identifier (NAI) and credentials. The NAI is a unique identifier for the MS. The credential is an authentication code computed by the MS in response to a Challenge Handshake Authentication Protocol (CHAP) if simple IP is used or a foreign agent challenge if mobile IP is used.

In step 4, if the mobile is successfully authenticated, the AAA sends an access accept containing the user subscription characteristics. The characteristics consist of two parts: an over-the-air (OTA) component; and an IP component.

In step 5, the PDSN receives and buffers the user IP subscription characteristics and forwards the user OTA subscription characteristics to the BS.

In step 6, the mobile sends SIP signaling over PPP/SO 33. SIP signaling is used to establish a virtual bearer connection with the CN. This is the IP bearer connection over which the packet flow is to be transported.

In step 7, the CN is triggered by SIP signaling (e.g., 183 session progress) and sends an RSVPPATH message to the MS. In the RSVP PATH message, the CN includes a standard RSVP object sender template and a sender traffic specification (Tspec), which characterizes the packet flow to be generated by the CN. In step 8, the PDSN forwards the RSVP PATH message to the MS. Upon receiving the RSVP PATH message, the MS calculates the desired QoS parameters (i.e., bandwidth and delay) for the received packet flow using the information contained in this message in step 9. The mobile station then sends an RSVP PATH message along the PATH to the CN to reserve resources. The RSVPPATH message contains flow specifications, filter specifications, and processing specifications specific to some systems that support the standards provided by the association named "3 rd Generation Partnership Project 2" (referred to herein as 3GPP2) and TR-45.5 (referred to herein as the cdma2000 standard).

The flow specification specifies the desired QoS. The flow specification is used to set parameters in the node's packet scheduler or other link layer mechanism. The flow specification in the reservation request will typically include a service level and two sets of numerical parameters: (1) "Rspec" (R stands for "reserved") that defines the desired QoS, and (2) the "Tspec" (T stands for "traffic") that describes the data flow. The format and content of Tspec and Rspec are determined by the integrated services model and are generally opaque to RSVP.

The filter specification defines packet filters for a packet flow whose QoS is defined by the flow specification. The filter specification is used to set parameters in the packet classifier. Data packets addressed in a session but not matching any filter specification for that session are processed as best effort traffic.

The processing specification, which is a new RSVP object, conveys the type of header compression that should be used on the packet flow.

Upon receiving the RSVP RESV message, the PDSN performs authorization based on PDSN loading and local policy, mobile reachability, and the user's IP subscription characteristics. If the PDSN rejects the RSVP RESV message, the PDSN sends an RSVPTerar message to the CN and a PATHTear message to the MS. Or if RSVP RESV is authorized, the PDSN checks the processing specification of the RSVP RESV message. The processing specification contains the type of header compression that the MS wants to use on the packet stream. The PDSN determines whether a new a10 connection is required. If necessary, the PDSN transmits an a11 Registration Update (RUP) message to the BS in step 10 in order to request a new a10 connection.

For example: if the header compression type is LLAROHC, the PDSN provides notification to the BS through A11 to establish a new A10 connection and initiate the establishment of the selected service option instance, such as SO61 with the MS.

If the header compression type is ROHC, the PDSN sends a notification to the BS through A11 to establish a new A10 connection and to initiate the establishment of an auxiliary service option instance such as SO33 (no RLP retransmission) with the MS.

The association between the header compression type and the SO may be done within the PDSN or BS. If this association is completed in the PDSN, the a11 RUP message will contain the SO number and the BS uses it to initiate service negotiation with the MS. If this association is done within the BS, the A11 RUP message will contain the header compression type and the BS associates it with the SO number and uses it to initiate service negotiation with the MS.

In step 11, the BS responds to an a11 Registration Acknowledgement (RACK) message. In step 12, the BS attempts to connect the SO specified in the a11 signaling message via a call assignment message (CLAM). In step 13, the BS connects the selected SO. In step 14, the BS sends an a11 RRQ (registration request) to establish an a10 connection, and in step 15, the PDSN responds with an a11 RRP (registration reply).

After successfully establishing the new a10 connection, the PDSN associates the newly established a10 connection with the packet filter obtained from the filter specification of the RSVP RESV message in step 9, step 16. This causes the PDSN to perform flow mapping on the packet flow that conforms to the packet flow filter description. The PDSN removes the processing specification from the RSVP RESV message and sends it towards the CN. If a new a10 connection is not established after an outdated one for some reason, the PDSN sends a TATHTear message to the MS.

From this point, the packet flow is processed from the CN to the MS through the PDSN. The PDSN performs the appropriate header compression on the data flow and forwards this packet flow to the appropriate a10 connection.

Notably, figure 2 shows one-way communication from the CN to the MS. For interactive two-way communication between the CN and the MS, both the MS and the CN are the source and the destination. Thus, in addition to the steps shown in fig. 2 and described in detail above, a symmetrical step is initiated from the MS. For example, the MS also sends RSVP path messages, and the PDSN forwards PSVP path messages to the CN as well. CN provides RSVP RESV message; and the PDSN forwards the RSVP RESV message to the MS. The RSVP RESV message from the CN would not have to trigger the PDAN to request the a10 connection setup as in step 10.

For the form of the existing a10 connection of the secondary SO33 that does not enable RLP retransmission, an embodiment uses the existing connection. According to an alternative embodiment, the BS establishes another auxiliary SO33 with the MS. In this case, if the MS rejects, the existing auxiliary SO33 is used to also transmit the new codec.

Fig. 2 shows a call flow in a spread spectrum communication system adapted for IP communication and capable of handling packet flows. Alternative communication systems may be used to provide the necessary information to process the packet stream. Such information is not limited to the specific information detailed in this example, but may include any information needed or desired by the system components. Likewise, the order of the steps may be varied as desired or dictated by the design of a given system. The call flow of fig. 2 is provided as an example of packet flow processing.

The embodiment described herein below is another method of providing flow processing and flow mapping information via RSVP messages. Flow handling and mapping information can be derived from standard RSVP objects conveyed in RSVP RESV messages, and no new RSVP objects need to be defined as in the previous method.

The call flow is the same as in fig. 2. One difference is that the RSVP RESV message contains only the flow specification and the filter specification in step 9. There is no processing specification to explicitly indicate what type of header compression the PDSN should use on the packet stream. Instead, the PDSN uses the flow specification to implicitly determine the header compression type.

Flow specifications include reservation specification (Rspec) and Traffic Spec (Tspec). Rspec describes the service rate and Tspec describes the tag recording parameters (recording rate, peak rate, recorded portion, maximum packet size) that characterize the traffic that the CN will generate. Rspec and Tspec together characterize a CDMA voice codec (e.g., 13-kbps of pure voice, 8-kbps of EVRC, 8-kbps of SMV, or 4kbps of SMV) that outputs one voice frame every 20 ms. The PDSN is configured to recognize CDMA voice codecs based on parameter values in the flow specification. If there is a match and the MS supports LLAROCH, the PDSN requests the BS to establish a new A10 connection and the BS establishes SO61 with the MS. If not, the PDSN concludes that the packet stream transmission is different from the real-time codec of the CDMA voice codec; thus, if the MS supports ROHC and there is no assisting SO33 at the time, the PDSN requests the BS to establish a new a10 connection and the BS establishes an assisting SO33 with the MS (RLP retransmission is not enabled).

It is possible that different codecs have the same Rspec and Tspec descriptions as CDMA codecs. For example, codec X is characterized by a service rate of 8kbps, a constant inter-packet spacing of 20 milliseconds, and a maximum packet size of 171 plus overhead of header overhead, as in the EVRC feature described above. This contribution recommends that a 0 byte header compression be applied to the packet stream transporting codec X as if it were an EVRC. Although the lower rate frame size of codec X may be different from that of EVRC, each lower rate frame can be inserted and filled into CDMA physical layer frames (full rate, 1/2, 1/4, or 1/8 rate).

Fig. 3 illustrates call flow processing, wherein the PDSN determines flow processing and/or mapping from "sniffing" SIP messages. Authentication (sniffing) refers to the process of checking messages for specific information. Typically, a node will authenticate to certain information and ignore all other information. In the embodiment illustrated in fig. 3, the PDSN authenticates to specific information desired to determine the processing of a given packet flow, and/or authenticates to the mapping of a given packet flow. The PDSN authenticates the SIP signaling message. The PDSN ignores other contents of the SIP message. Alternate embodiments may apply other content in the SIP message for these processes or other operations of the PDSN.

The embodiment illustrated in fig. 3 provides an alternative method of determining flow processing and flow mapping information, where such determination is based on PDSN error-resilient Session Initiation Protocol (SIP) messages. This method relies on the PDSN authenticating the SIP message to determine the IP address, port number, and codec of the new packet stream to be generated by the CN. This provides the PDSN with sufficient information to determine flow processing and flow mapping. The PDSN also determines whether a new a10 connection is needed to transport the packet stream. If necessary, the PDSN requests the BS to establish an A10 connection, and the BS initiates the establishment of a new service instance with the MS.

Authentication of SIP messages requires the PDSN to recognize that the IP packets carry the SIP messages and select the basic information from the SIP messages. The PDSN checks the destination port number of the packet. If it equals 5060, the transport payload carries the SIP message. Notably, there are a plurality of SIP messages and fields. The PDSN notes the SIP invite and SIP 200 OK messages and may choose to ignore other SIP messages. Notably, SIP defines a plurality of messages. SIP INVITE the message indicates that a user or service is being invited to participate in a session. The SIP 200 OK message indicates that the request has succeeded. In SIP INVITE and the SIP 200 OK message, the PDSN notes a connection field carrying IP address information, a media field carrying port number information, and an attribute field carrying codec type. Based on the codec type, the PDSN determines which type of header compression is used on the packet flow. For example, if the codec type indicates a CDMA codec (e.g., voice only, EVRC, or SMV), link layer assisted robust header compression (LLAROHC) will be used; if the codec type indicates a codec other than a CDMA codec, robust header compression (ROHC) will be used. Alternative systems may support any of several codec types, and the specific details provided herein are used as examples.

After the PDSN determines the type of header compression, the PDSN determines whether a new a10 connection is needed for the new packet flow. If necessary, the PDSN requests the BS to establish an A10 connection, and the BS initiates the establishment of a new service instance with the MS. After successfully establishing the a10 connection, the PDSN associates the a10 connection with the packet filter obtained from the authentication of the SIP messages, i.e., the connection and media fields of the SIP INVITE and SIP 200 OK messages.

Fig. 5 illustrates an MS500 adapted to process a packet flow. MS500 includes an antenna 510, a receiver 520, and a transmitter 530. The receiver 520 and the transmitter 530 are each coupled to a Central Processing Unit (CPU) 540. The CPU540 and the memory 550 are each coupled to a communication bus 560. Also, the packet flow establishing unit 570, the packet flow processing unit 580, and the packet flow determining unit 590 are each coupled to the communication bus 560. The packet flow determination unit 590 determines whether the communication is bidirectional or unidirectional. The packet stream establishing unit 570 determines the details of the packet stream such as codec type, header compression. The packet stream establishing unit 570 and the packet stream determining unit 590 are involved in the initial access and are established for transmission of a packet stream, such as illustrated in fig. 2 and 3. Once communication is established, the packet flow processing unit 580 processes the packet flow according to the established specific parameters.

The present invention provides a flexible method for communicating packet flow parameters in RSVP messages without relying on a Differentiated Services Coding Point (DSCP) that is passed in fields of an IP header, a protocol type and a well-known port number. Messages such as RSVP messages may be used for both bi-directional and unidirectional packet flows.

Existing messages are used to provide packet flow information to achieve efficient over-the-air source allocation and usage criteria. In one embodiment, a new bearer connection for communication, i.e., a new a10 connection, is not established until the RSVP reservation is authorized. This avoids the interruption of the requirement for bearer connection (i.e. auxiliary SO, A8/a10 connection) upon rejection.

In an alternative embodiment, additional service instance setups may be initialized as illustrated in FIG. 6. The call flow diagram of fig. 6 illustrates the steps for additional service instance establishment when the MS has been active with the established primary service instance, as follows:

at point a, the PDSN determines to establish additional service instances; the PDSN sends an a 11-registration update to the PCF. The a11 registration update message allows the PDSN to indicate the applied header compression algorithm. The PDSN starts a timer associated with the registration update message (referred to as timer "T' regipd").

At point b, the PCF sends an A9-BS service request message to the BS to request additional service instances and starts a timer "T_bsreq9"timer. The mapping between the header compression algorithm and the service options is performed in the PCF or BS. According to one embodiment, the determination is made by TSG-A (technical Specification group). If the mapping is performed by the PCF, no changes are made to the existing a9-BS service request message. If the mapping is performed in the BS, the PCF will instruct the application of the header compression algorithm to the BS in the A9-BS service request message. For example, the mapping table may be specified as follows:

header compression algorithm	Service options
		ROHC	SO33
LLAROHC	SO60 or SO61

In step c, the BS sends an additional service request message to the MSC and starts a timer "T" called timer₃₀₃"meter ofA timer is used to reconnect additional service instances.

In step d, the MSC sends an allocation request message to the BS requesting allocation of radio resources and an A8 (e.g., user traffic) connection between the BS and the PCF. MSC then starts a timer T₁₀"timer. Upon receiving the assignment request message from the MSC, the BS terminates the timer T₃₀₃。

In step e, the BS responds to the a9-BS service response. The PCF terminates the timer T after receiving the a9-BS service response message_bsreq9。

In step f, the PCF responds to the a 11-registration acknowledgement after receiving a successful a9-BS service response message from the BS. The PDSN terminates the timer T' regipd.

In step g, the BS may send a call assignment message on a traffic channel of the radio interface to initiate the establishment of a CC state machine (call control state machine).

In step h, the BS sends one of the following messages to the MS to invoke the additional service option connection: i) a service connect message; ii) a general handover direction message; or iii) a generic handover direction message.

In step i, service negotiation may be performed between the MS and the BS.

In step j, the MS responds with a service connect complete message after completing the service negotiation procedure.

In step k, the BS sends an a 9-setup-A8 message to the PCF to establish an A8 (i.e., user traffic) connection over an a9 (e.g., signaling) connection between the BS and the PCF for the additional service instance. Next, the BS starts a timer called "T_A8-Setup"timer.

In step 1, the PCF identifies that there is an a10 connection associated with this mobile station and that an additional a10 connection needs to be established. The PCF sends an a 11-registration request message to the corresponding PDSN. The PCF starts a timer called "T' regreq".

In step m, the PDSN accepts the connection by returning an a 11-registration response message with an accept indication.

In step n, the PCF responds with an a 9-connect-A8 message to complete the establishment of the A8 (e.g., user traffic) connection for this packet service request. Upon receiving the A9-CONNECTION-A8 message from the PCF, the BS terminates the timer T_A8-Setup。

In step o, after the wireless service connection and the a10 connection have been established, the BS transmits an assignment complete message to the MSC. Next, when the MSC sends an assignment request message (see step d), the MSC terminates the timer T₁₀。

Notably, the PDSN can add a new a10 connection by initiating a request using a message supported by the system. The PDSN sends an a 11-registration update message to the PCF requesting the addition of a new a10 connection. The PDSN sends an a 11-registration update message with the encoded field in the message set to "add new connection" to request the PCF to establish a new a10 connection. The PDSN then starts a timer associated with the registration update (referred to as "T' regipd") after sending the a 11-registration update message, and waits for an a 11-registration acknowledgement message from the PCF.

If the timer T' regipd times out, the PDSN resends the A11-registration update message to the PCF a configurable number of times. After a configurable number of retransmissions without a response from the PCF, the session establishment procedure may be considered as a failure, however the existing a10 connection will remain connected.

If the requested operation can be successfully supported by the BS, PCF and MSC, the PCF sends an A11-registration confirmation message to the PDSN confirming that the requested A10 connection was accepted.

After receiving the a 11-registration update message with the encoded field set to the "add new connection" message, the PCF will send an a9-BS service request message to the BS if the PCF supports the requested a10 connection. If the MSC and BS support a new connection, the PCF will so indicate by setting the status field in the message to "New connection accepted". Upon receipt of this message, the PDSN will terminate the timer T' requpd when an a 11-registration update message is sent, and stop when an a11-Ack is received.

After receiving the a 11-registration update message with the encoded field of the message set to "add new connection", if the PCF does not support the requested a10 connection, or the requested connection is rejected by the a9-BS service response message received from the BS, the PCF will so indicate by setting the status field of the message to "reject new connection". Upon receiving this message, the PDSN terminates the timer T' requpd.

If the PDSN fails to receive the a 11-registration update message from the PCF, the PDSN may retransmit the a 11-registration update message a configurable number of times before considering the new establishment as failed.

Each of the messages described above may include any number of fields and encodings, as defined by the system. For example, as suggested by the design in 3GPP2, the a 11-registration update message includes an encoding. When this message requires an additional connection or requests an update to an existing connection, the encoded information element is included. The coding unit identifies the result of processing the a 11-registration update message. For example, the code (decimal) 33 indicates "add new connection".

Likewise, the A11-registration update message has an associated status element that identifies the result of processing the A11-registration update message. For example, state (decimal) 149 indicates "accept new connection"; and state (decimal) 150 indicates "reject new connection".

In addition, normal vendor/organization specific extensions (NVSE) -application type 0AH (hexadecimal value) indicates a header compression algorithm. The application subtype is then used to identify a specific algorithm. For example, (hexadecimal value) 01H identifies robust header compression (ROHC), while (hexadecimal) 02H identifies link layer assisted ROHC (llaohc). The MN session reference ID field is used to uniquely identify the packet data service instance in the mobile station. The MN session reference ID is passed from the mobile station to the PCF. For application type 0AH (header compression algorithm), the MN session reference ID field contains a header compression algorithm in the 11 th place.

The multi-channel streaming protocol (MCFTP) is defined as a new PPP protocol type. MCFTP carries information about the rod binding between packet flows and the SR _ ID used for 0 byte header compression, such as how flows should be mapped to the underlying service instance connection between the MS and PDSN. MCFTP also transfers IR-static information from the MS to the PDSN if header removal mode is used between the MS and the PDSN. The information elements of MCFTP are designed according to type, length, value (TLV) principles that allow simple extensions of the protocol as needed.

The PPP will reach the network layer protocol stage before any MCFTP packets can be communicated. The MCFTP packet is illustrated in fig. 9. More than one MCFTP packet may be encapsulated in the PPP information field, with the protocol number indicating protocol x0289 (MCFTP). MCFTP uses three basic message formats:

MCFTP-request (operation code ═ 1)

MCFTP-response (operation code 2)

MCFTP-reject (operation code ═ 7)

The CFTP-request message format is sent with a code equal to 1 and contains the fields shown in table 1.

TABLE 1 MCFTP request message Format

Field(s)	Length of field	Value of
			Code	1 byte	1
ID	1 byte	ID field identifying a request set by a requester
			Length of	2 bytes	Full length of packet in bytes
Optional item	Variable (TLV format)	Traffic Flow Template (TFT): type 1

An MCFTP-response is sent in response to the MCFTP-request message being successfully received and processed. It is simply a MCFTP packet that includes a null body or IR-static information. The MCFTP-response message format is sent with a code equal to 2 and includes the fields shown in table 2.

TABLE 2 MCFTP response message Format

Field(s)	Length of field	Value of
			Code	1 byte	2
ID	1 byte	ID field for matching corresponding requests
			Length of	2 bytes	Full length of packet in bytes
Options for	Variable (TLV format)	IR-static: type 1

The MCFTP-reject message is sent in response to the MCFTP-request message not being able to be processed, such as an MCFTP-request message that cannot be processed when the receiver is unable to identify a reception option or sub-option. The MCFTP-reject packet format is sent with a code equal to 7 and contains the fields shown in table 3.

Table 3 LMCFTP reject packet format

Field(s)	Length of field	Value of
			Code	1 byte	7
ID	1 byte	For matching correspondencesID field of request
			Length of	2 bytes	Full length of packet in bytes
Reject-code	1 byte	-1 packet filter increase failure-2 packet filter unavailable-3 unsuccessful TFT processing-4 estimation priority contention-5 streaming processing is not supported

According to one embodiment, a method for flow mapping, a simplified MCFTP method, is combined with a localized RSVP method. In particular, the simplified MCFTP is only used for 0-byte header compression to establish a binding between SR _ ID (service related identification) and IP flows, since there is no context ID (cid) in the 0-byte header compressed NHP packet. The simplified MCFTP operates over PPP instead of UDP, while MCFTP contains link layer parameters such as SR _ ID binding for 0 byte header compression removal mode and IR-static link layer parameters. Localized RSVP is used to trigger sending of MCFTP requests to the PDSN of the mobile node. This method uses standard localized RSVP messages and objects. Existing RSVP targets deliver enough information for the PDSN to determine the codec characteristics and thus which header compression method should be used on the packet flow. 3GPP 2-specific RSVP objects are not required. The PDSN also determines whether a new a10 connection is needed to transport the IP flow. If desired, the PDSN requests the RN to establish an A10 connection, the RN initiates the establishment of a new service instance with the MS, and service negotiation may be performed between the MS and the RN. After establishing the new service instance, the PDSN will send MCFTP over PPP to indicate the binding between the IP flow and the SR _ ID. If header removal mode is used, the MS will send IR-static parameters to the PDSN using MCFTP over PPP.

Fig. 7 illustrates how the PDSN and MS determine the flow processing and mapping used by the Corresponding Node (CN) to generate the packet flow.

1. The mobile station establishes the primary service instance (i.e., SO33 that allows RLP retransmission). The mobile station then sends SIP and RSVP messages through the primary service instance that provides reliable over-the-air transport. The mobile station establishes a PPP session with the PDSN. During the PPP IPCP phase, the mobile station indicates its header compression capacity (e.g., ROHC, llaohc, VJHC) to the PDSN.

The PDSN sends an access request to the AAA, which contains the mobile station's Network Access Identifier (NAI) and credentials. The credential is an authentication code that the mobile station computes in response to CHAP (if simple IP is used) or FA challenge (if mobile IP is used).

3. If the mobile station is successfully authenticated, the AAA sends an access accept containing the user subscription characteristics.

The PDSN may forward the user subscription characteristic to the RN. At this point, the PDSN can establish packet filters for the primary service instance, as shown below. If the destination IP addresses are matched, all incoming IP packets are matched to the GRE tunnel (A10 connection) x.

TABLE 4 subscriber subscription profile information

GRE key	x
		Source IP address	*
Source port number	*
		Destination IP address	MS IP address
Destination port number	*
		IP protocol	*

Notably, the destination "", indicates a wildcard match.

5. After a period of time, the mobile station and the CN exchange SIP signaling.

6. Triggered via SIP signaling (e.g., 183 session progress), the mobile station sends a PATH request message to the PDSN to notify the local RSVP agent to initiate an RSVP reservation setup on behalf of the sender (i.e., CN). The PATH request message is destined for the PDSN. During IPCP, the mobile station discovers the IP address of the PDSN. The path request message with LI (localized identity) identification group is identical to the standard path message, different from the message type field. The path request message includes a session target, a sender template defining the intended sender, and a session specification (TSpec) based on the mobile user's desire or best estimate of the incoming traffic characteristics, or based on application layer session signaling (e.g., SIP) prior to transmission.

7. When the PDSN or local RSVP agent accepts the path request message, the PDSN detects that the message is intended to remain with the visited network. The message type indicates that the proxy should initiate RSVP reservation of the downstream flow and use the information in the message to populate fields in the path message. Accordingly, the PDSN transmits a path message to the mobile node having the LI flag set. Because the session object and sender template are initially set to "backwards", the proxy can directly copy these entries as is to the path message.

8. The mobile node responds with a RESV message with the LI flag set.

9. Upon receiving the RSVP RESV message, the PDSN performs authorization based on PDSN loading and local policy, mobile reachability, and the user's IP subscription characteristics. If authorized, the PDSN determines flow processing and mapping based on the flow specification and the filter specification:

the PDSN uses the flow specification to determine which header compression method should be used on the packet flow. The flow specification includes a reservation specification (Rspec) and a traffic specification (Tspec). Rspec describes the service rate and Tspec describes the tag recording parameters (recording rate, peak rate, recorded portion, maximum packet size) that characterize the traffic that the CN will generate. Rspec and Tspec together characterize the CDMA speech codec (13-kbps pure speech, 8-kbps EVRC, 8-kbps SMV, or 4-kbps SMV) outputting one speech frame every 20 ms. It is noted that alternative codecs may have the same Rspec and Tspec descriptions. For example, codec X is characterized by a service rate of 8kbps, a constant inter-packet spacing of 20-ms, and a maximum packet size of 171 bits plus header overhead, as is the same as the EVRC feature. Header compression of 0 bytes is applied to the packet stream that transports codec X as if it were EVRC. Although the lower rate frame size of codec X is different from that of EVRC, each lower rate frame can be inserted and filled in CDMA physical layer frames (full rate, 1/2, 1/4, or 1/8 rate).

The PDSN is configured to recognize the CDMA voice codec based on the parameter values in the flow specification. If there is a match and the MS supports LLAROHC, the PDSN requests the RN to establish a new A10 connection and the RN establishes SO61 with the MS. If not, the PDSN concludes that the IP stream transmission real-time coding and decoding is not the CDMA voice coding and decoding; thus, if the MS supports ROHC and at the same time has no auxiliary data service precursor SO33, the PDSN requests the RN to establish a new a10 connection and the RN establishes an auxiliary SO33 with the MS (RLP retransmission is prohibited).

The PDSN uses a filter specification for the flow map. The filter specifies the source address and port number that carry the packet flow to be generated by the CN. If the PDSN requests a new a10 connection, the PDSN associates the new connection with the packet flow described in the filter specification.

10. If the PDSN determines that the packet flow expects a new A10 connection, the PDSN sends an A11 Registration Update (RUP) message to the RN requesting a new A10 connection. This message conveys an indication that triggers the RN to establish an appropriate SO with the MS. This message may also convey QoS parameters that may be needed in the SO establishment.

11. If the RN can support the new A10 connection requested by the PDSN, the RN responds with an A11 Registration Acknowledgement (RACK) message.

The RN attempts to connect the SO specified in the a11 signaling message to the MS via the call allocation message.

The RN and the mobile station will perform service negotiation agreed on the SO. In this example, the MS requests SO32 to specify a header removal mode.

RN allocates SR _ ID and connects SO 62. Table 5 indicates RN establishment.

TABLE 5 RN setup information

SO	33
		SR_ID	1 (Main SI established in step 1)
GRE key	x
SO	62
		SR_ID	2
GRE key	y

RN sends A11 RRQ to establish a new A10 connection. In the a11 RRQ message, the RN also indicates the SR _ ID and over-the-air connected service options.

PDSN responds with a11 RRP. Upon successful establishment of the new a10 connection, the PDSN associates the newly established a10 connection with the forward packet filter obtained from the filter specification of the RSVP message. At this point, the PDSN may establish packet filters for the primary and secondary service instances. Thus, the PDSN will first apply the packet filter to the auxiliary service instance.

TABLE 6 design of packet filters

GRE key	x
		Source IP address	*
Source port number	*
		Destination IP address	MS IP address
Destination port number	*
		IP protocol	*
		GRE bond	y
Source IP address	CN IP Address
		Source port number	CN port number
Destination IP address	MS IP address
		Destination port number	MS port number
IP protocol	UDP
		Head treatment	LLAROHC head removal mode

The PDSN sends an MCFTP request to the MS over PPP (primary service instance), indicating a binding of SR _ ID and IP flow.

The MS sends an MCFTP response to the PDSN indicating SR-static information, while using SO62 (llaohoc header removal mode) in this example.

IP packets may start to flow between the application and the CN.

The flow mapping and processing of ROHC call flows are similar to llarcoch except that MCFTP is not required when a Context Id (CID) is included in each ROHC packet so that the receiving party can distinguish IP flows by CID.

Fig. 8 depicts how the PDSN and MS determine flow processing and mapping of packet flows generated by the Corresponding Node (CN) of the ROHC. Note that steps 1 to 9 are shown in fig. 7. The following description starts with step 10 in fig. 8.

10. If the PDSN determines that the packet flow requires a new A10 connection, the PDSN sends an A11 Registration Update (RUP) message to the RN requesting a new A10 connection. This message will trigger the RN to establish an indication of the appropriate SO with the MS. This message also conveys the quality of service (QoS) parameters needed in the SO establishment.

11. If the RN can support the new A10 connection requested by the PDSN, the RN responds with an A11 Registration Acknowledgement (RACK) message.

The RN attempts to connect SO33 to the MS via a call assignment message.

RN allocates SR _ ID and connects SO33 to the mobile station.

TABLE 7 RN establishment

SO	33
		SR_ID	1 (Main SI established in step 1)
GRE key	x
SO	33
		SR_ID	2
GRE key	y

The RN sends an A11 RRQ to establish a new A10 connection. In this message, the RN also indicates the SR _ ID and over-the-air connected service option.

PDSN response to a11 RRP. Upon successful establishment of the new a10 connection, the PDSN associates the newly established a10 connection with the forward packet filter obtained from the filter specification of the RSVP message. At this point, the PDSN may establish packet filters for the primary and secondary service instances. Thus, the PDSN will first apply the packet filter to the secondary service instance.

TABLE 8 packet filter information

GRE key	x
		Source IP address	*
Source port number	*
		Destination IP address	MS IP address
Destination port number	*
		IP protocol	*
		GRE key	y
Source IP address	CN IP Address
		Source port number	CN port number
Destination IP address	MS IP address
		Destination port number	MS port number
IP protocol	UDP
		Head treatment	ROHC

Both the MS and PDSN send IR (initialization and refresh) packets on the second SO 3.

IP packets can flow between the application and the CN.

MCFTP offers several advantages for LLA-ROHC. The PDSN transmits the packet filter and SR _ ID binding to the MS using MCFTP. The need for MCFTP is illustrated in the following TE-MT (terminal equipment-mobile terminal) example. For some reasons, a TE (e.g., a laptop) may desire to establish two voice over IP (VoIP) sessions simultaneously, each using an EVRC. Although the MT (e.g., a network model handset) can authenticate RSVP messages containing packet filter information for two VoIP flows, the MT does not know the binding between the packet filter and the SR _ ID unless the PDSN uses MCFTP to inform the MT of the binding. Note that: in this example, the RSVP parameters for two VoIP sessions using EVRC appear to be almost the same as MT.

In the header removal mode, the MS needs to use MCFTP to pass "whole header" information to the PDSN. Notably, LLA-ROHC is link layer assisted header compression. Also, the header removal mode is a 3GPP2 dedicated mode; it is not a problem to establish a 3GPP2 dedicated link protocol (simplified MCFTP) to assist this operation.

For ROHC, MCFTP is not needed even when the TE wants to establish two real-time sessions simultaneously. For example, non-CDMA codecs that cannot utilize 0-byte header compression are used. Based on the RSVP parameters, the MT that authenticates the RSVP messages will know whether the two real-time sessions require similar over-the-air QoS. This example also considers the following two cases:

1. if the session requires similar over-the-air QoS, only one second SO33 is needed for both flows, and the MT can map the packet filters of the flows to the same SR _ ID corresponding to the second SO 33. Based on the RSVP parameters, the network side will conclude the same, causing the PDSN to trigger the RAN to set up a second SO33 for both flows. During ROHC initialization, the MT sends ROHC IR packets (via the second SO33) to the PDSN, and the header compression state of each flow is represented by one CID.

2. If the session requires different over-the-air QoS (e.g., one requires no RLP retransmission and the other requires an RLP retransmission with a maximum retransmission equal to 1), two second SOs 33 are required. The MT, based on RSVP parameters, knows which IP flow should be sent on which second SO 33; therefore, the MT knows the binding between the packet filter and the SR _ ID. During ROCH initialization, the MT transmits ROHC IR packets for each real-time session on the appropriate second SO33 and receives IR packets by the PDSN on the corresponding a10 connection. The IR packet has enough packet filter information for the PDSN to bind it with the appropriate a10 connection.

PPP frames (rather than UDP datagrams) are recommended for MCFTP, based on a layering principle. Using MCFTP transfer: i) binding between packet filters and SR _ ID; and ii) the "entire header" information when the LLA-ROHC header removal mode is used, MCFTP should be transmitted at the link layer (e.g., PPP). The use of UDP for transmitting MCFTP is strictly a "layer violation" and, therefore, is not recommended. The method described herein relies on existing RSVP parameters (flow specification and filter specification) to set up the packet filter in the PDSN. Examples of flag recording parameters for setting the EVRC codec are listed below:

recording depth ═ 1 (source is constant bit rate)

Peak rate (176 bits/full rate frame) × (50 full rate frame/sec) + (320IP overhead bits/frame) × (50 frames/sec) ═ 24.8kbps

176 bits +320 bits for maximum packet size 496 bits for overhead

The existing RSVP parameters are sufficient to set up the packet filter within the PDSN. The method described here is very clear with no delamination violations. Furthermore, using standard RSVP objects and behaviors, no 3GPP 2-specific RSVP objects are required. Simplified MCFTP is limited to link layer assisted 0-byte header compression. This simplified MCFTP is easy to implement for both the MS and PDSN. The method does not require some Application Programming Interface (API) between the laptop and the mobile terminal, while it relies on the network to initiate the establishment of the SO and negotiate the service configuration between the mobile station and the network. Although an interface between the MCFTP module and the LLAROHC module is required to transfer information of TFT (traffic flow template) and SR _ ID, it can be fully controlled by the mobile terminal.

Those of skill in the art would understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

Those of skill would further appreciate that the various illustrative logical blocks, modules, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the present disclosure

The scope of the invention.

The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with: a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination of devices designed to perform the functions described herein. A general purpose processor is preferably a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or other such configuration.

The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.

The previous description of the preferred embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without the use of the inventive faculty. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (25)

1. A method for processing a packet stream in a mobile communication system, comprising:

determining packet flow parameters for at least one request packet flow; and

at least one packet flow parameter is provided to the infrastructure element by a reservation message indicating flow processing of the packet flow.

2. The method of claim 1, wherein at least one packet flow parameter is header compression information.

3. The method of claim 1, wherein at least one packet stream parameter is codec information.

4. The method of claim 1, wherein the reservation message is a resource reservation protocol message.

5. The method of claim 1, wherein a packet flow has an associated quality of service requirement, and wherein a packet flow is mapped to a link based on a quality of service requirement.

6. A method for processing a packet stream in a communication system, comprising:

establishing a bearer connection between a transmitter and a receiver of a packet stream;

receiving at least one packet stream parameter of a packet stream from a transmitter; and

at least one packet stream parameter is provided to a receiver.

7. The method of claim 6, wherein the transmitter is a remote user and the receiver is an internet node.

8. The method of claim 6, further comprising:

a new link for processing the packet flow is established.

9. An apparatus for processing a packet data stream in a communication system, comprising:

means for determining at least one packet flow parameter for the requested packet flow;

for providing at least one packet flow parameter to an infrastructure element in a communication system via a reservation message indicating flow processing of a packet flow.

10. An apparatus for processing a packet stream in a communication system, comprising:

means for establishing a bearer connection between a transmitter and a receiver for a packet stream;

means for receiving at least one packet stream parameter of a packet stream from a transmitter;

means for providing at least one packet stream parameter to a receiver.

11. A remote station apparatus comprising:

a control processor for processing a packet stream; and

a packet flow determination unit coupled to the control processor, the packet flow determination unit being adapted to determine at least one packet flow parameter of the packet flow.

12. The remote station of claim 11, further comprising:

a packet flow setup unit coupled to the control processor, the packet flow setup unit being adapted to provide at least one packet flow parameter in the reservation message.

13. The remote station of claim 12, further comprising:

a packet stream processing unit coupled to the control processor, the packet stream processing unit for processing the packet stream in accordance with at least one packet stream parameter.

14. A remote station as defined in claim 13, wherein the at least one packet flow parameter is header compression information.

15. A remote station as defined in claim 13, wherein the at least one packet stream parameter is codec information.

16. A remote station as defined in claim 11, wherein the reservation message is a resource reservation protocol message.

17. A method for processing a packet stream in a communication system, comprising:

establishing a bearer connection between a transmitter and a receiver, the bearer connection supporting internet protocol communications;

monitoring transmissions on the bearer connection for packet flow parameter information;

detecting packet stream parameter information of a packet stream; and

the packet stream parameter information is provided to the receiver in response to detecting the packet stream parameter information.

18. The method of claim 17, wherein the bearer connection is established using session initiation protocol.

19. The method of claim 17, wherein the flow treatment of the packet flow is determined based on packet flow parameter information.

20. The method of claim 17, wherein the packet flow parameter information is included in an invite message sent over the bearer connection.

21. A computer readable medium embodying a method for processing a packet stream in a communication system, the method comprising:

establishing a bearer connection between a transmitter and a receiver, the bearer connection supporting internet protocol communications;

monitoring transmissions on the bearer connection for packet flow parameter information;

detecting packet stream parameter information of a packet stream; and

the packet stream parameter information is provided to the receiver in response to detecting the packet stream parameter information.

22. The computer-readable medium of claim 21, further adapted to:

determining a flow process based on the packet flow parameter information; and

the flow map is determined based on a quality of service associated with the packet flow.

23. An apparatus for providing additional instances of services in a wireless communication system, comprising:

receiving a request for a plurality of service options for a mobile station;

determining a need to establish an additional service instance at a packet data serving node;

sending a registration update message to a packet control function node identifying a header compression algorithm;

a registration confirmation is received.

24. The method of claim 23, further comprising:

starting a first timer for the registration update message; and

the registration update message is retransmitted a predetermined number of times after the first timer expires.

25. A method for receiving an additional service instance at a wireless communication device, further comprising:

establishing a first service option;

requesting a second service selection concurrent with the first service selection;

receiving a message identifying a second service option connection;

establishing a second service option connection; and

communication is performed over the first and second service option connections.