[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

US6697352B1 - Communication device and method - Google Patents

Communication device and method Download PDF

Info

Publication number
US6697352B1
US6697352B1 US09/353,853 US35385399A US6697352B1 US 6697352 B1 US6697352 B1 US 6697352B1 US 35385399 A US35385399 A US 35385399A US 6697352 B1 US6697352 B1 US 6697352B1
Authority
US
United States
Prior art keywords
data
data packets
data structure
packet
transmission reliability
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
US09/353,853
Inventor
Reiner Ludwig
Farooq Khan
Bela Rathonyi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from EP98113212A external-priority patent/EP0973302A1/en
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Assigned to TELEFONAKTIEBOLAGET L M ERICSSON (PUBL) reassignment TELEFONAKTIEBOLAGET L M ERICSSON (PUBL) ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: KHAN, FAROOQ, LUDWIG, REINER, RATHONYI, BELA
Priority to US10/644,473 priority Critical patent/US7382763B2/en
Application granted granted Critical
Publication of US6697352B1 publication Critical patent/US6697352B1/en
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08Protocols for interworking; Protocol conversion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08Protocols for interworking; Protocol conversion
    • H04L69/085Protocols for interworking; Protocol conversion specially adapted for interworking of IP-based networks with other networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/321Interlayer communication protocols or service data unit [SDU] definitions; Interfaces between layers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/325Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the network layer [OSI layer 3], e.g. X.25
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation

Definitions

  • the present invention relates to a device and method for sending data packets, for example over a link establishing a connection between a computer and a packet exchange network such as the so called Internet.
  • Internet simply refers to a network consisting of other networks, so that the world wide “Internet” is only an example, albeit a very well known one.
  • Protocols are sets of rules that allow the communication between a sending end and a receiving end, as the rules specify how and in what form data to be sent has to be prepared, such that the receiving end may interpret the data and react in accordance to protocol defined rules to which both partners in the communication adhere.
  • Protocol layering An important concept for allowing the exchange of data between different networks, and thereby between numerous kinds of software and hardware, is that of protocol layering. This means that a number of protocols (sometimes also referred to as a suite) is organized in a hierarchy of layers, where each layer has specific functions and responsibilities. This will briefly be explained by referring to an example illustrated in FIGS. 3 to 5 . A more detailed description of this concept is e.g. given in “TCP/IP Illustrated, Volume 1, The Protocols” by W. Richard Stevens, Addison-Wesley, 1994.
  • the Transmission Control Protocol (TCP) and the Internet Protocol (IP) are examples of protocols according to which communication over the Internet may be handled. What is commonly referred to as TCP/IP, however, comprises other protocols as well.
  • the so-called TCP/IP suite has four layers, as shown in FIG. 3 .
  • the link layer handles the input and output of data into the physical communication media, e.g. a cable or a radio connection. It typically is implemented in the device driver in the operating system and the corresponding network interface card in the computer.
  • the network layer handles the movement of packets around the network, e.g. routing. IP is an example of a network layer protocol.
  • the transport layer provides a flow of data for the application layer above. For example, TCP is at the transport layer.
  • An alternative to TCP is the User Datagram Protocol (UDP).
  • the application layer is constituted by the application program sending or receiving data, e.g. an e-mail program.
  • a communication between two points then has the schematic form shown in FIG. 4 .
  • Data is first handed down through the layers and input into the physical connection on the sending side, and then handed up through the layers on the receiving side. This is indicated by the solid line arrows.
  • the elements handling the data at a given layer in accordance with a protocol specified for that layer e.g. TCP at the transport layer in the example of FIG. 4 are also referred to as peers.
  • the transport layer in the example of FIG. 4 is handled by a TCP peer.
  • the physical connection shown at the bottom of FIG. 4 may again consist of one or more protocol layers of its own, depending on the type of connection. This will be explained in more detail further on.
  • FIG. 5 illustrates the mechanism of passing data through the layers.
  • the typical basic structure of a packet has two parts, namely a header and a payload part.
  • the header contains information on the type of data contained in the payload part and communication control information for the respective layer.
  • user data is processed by adding a header.
  • the resulting data unit or packet is passed to the transport layer, where e.g. a TCP header is added.
  • This TCP header contains information for the TCP peer on the receiving side.
  • the resulting packet is sometimes also referred to as a TCP segment.
  • this TCP segment is passed to the network layer, where in the example of FIG. 5 an IP header is added that e.g. contains routing information.
  • the resulting packet is also referred to as an IP datagram.
  • the IP datagram is passed to the link layer, where a header associated with the link layer protocol (LLP), e.g. the Point-to-Point Protocol (PPP), is added.
  • LLP link layer protocol
  • PPP Point-to-Point Protocol
  • the resulting packet is often called a frame.
  • the frame also receives a start flag and an end flag, such that a receiver may recognize where a frame begins and where it ends.
  • This process of embedding a packet of a higher layer in a larger packet of a lower layer is referred to as encapsulation.
  • the user data is extracted by steps of de-encapsulation in the opposite order of what is shown in FIG. 5 .
  • the above description only refers to an example, and variations are possible. For example, some protocols not only add headers, but also trailers.
  • LCP Link Control Protocol
  • FIG. 4 schematically shows an example of a communication between an IP-host 1 and an IP-host 2 .
  • the top part of the figure represents the physical communication path, and the lower part of the figure shows the logical communication path associated with the various protocols employed.
  • the example of FIG. 6 relates to a connection to the Internet via a GSM network.
  • IP-host 1 can e.g. be a laptop computer.
  • the terminal adaptation function TAF can be fulfilled e.g. by a PCMCIA interface card that is connected to the mobile station MS, e.g. a cellular telephone.
  • the mobile station MS communicates with a base transceiver station BTS, which in turn is connected to a base station controller BSC.
  • the connection to a public switched telephone network PSTN is accomplished by a modem in the interworking function IWF of the mobile switching center MSC associated with the base transceiver station BTS.
  • IWF the interworking function
  • GSM Global System for Mobile Communications
  • the PSTN provides the connection to an Internet services provider ISP, who in turn provides a gateway to the Internet.
  • ISP Internet services provider
  • a TCP peer, an IP peer and a PPP peer are implemented at IP-host 1 .
  • the corresponding TCP peer and an IP peer reside in IP-host 2 , whereas an IP peer and PPP peer are implemented at the Internet services provider ISP.
  • the different layers are “transparent”. This means that the peers in a layer are oblivious to what happens in another layer.
  • the PPP peers establish a pseudo-dedicated PPP connection between the IP-host 1 and the Internet services provider ISP.
  • the two PPP peers operate independently of what type of physical connection is used, i.e. independently of which specific protocols are provided in lower layers.
  • the PPP peers pass packets coming from higher layers transparently, i.e. with out regarding their contents.
  • a forward error correction (FEC) layer and an interleave layer are provided between the mobile station MS and the base transceiver station BTS, a layer 2 relay (L 2 R) and a radio link protocol (RLP) connection are established between the terminal adaptation function TAF and the mobile switching center MSC, and V.42 and V.32 interfaces are established between the interworking function IWF and the Internet service provider ISP. All of these protocols are known and, except for RLP, will not be discussed further.
  • FEC forward error correction
  • L 2 R layer 2 relay
  • RLP radio link protocol
  • RLP is responsible for transporting data units from higher layers, this is not done by means of encapsulation, i.e. by one higher layer data unit being fit into one lower layer data unit, much rather RLP performs segmentation, i.e. one higher layer data unit is divided into a plurality of segments and each segment is placed into a lower layer data unit.
  • the RLP data units are smaller than the higher layer data units (e.g. a PPP frame) they transport.
  • embedding comprises both encapsulation and segmentation.
  • packets associated with different protocols are sometimes referred to differently, e.g. frame, segment, datagram etc.
  • Packet generically as meaning any data unit that has a defined syntax, and a data structure specified by a predetermined protocol.
  • Data structure means that specific data at defined locations (addresses) has a specific meaning defined by the respective protocol. An example of this will be explained in connection with FIG. 7, in which a frame structure in accordance with the high-level data link control protocol (HDLC) is shown.
  • HDLC high-level data link control protocol
  • PPP has adopted many of the basic features of HDLC.
  • FIG. 7 shows a HDLC frame that has an address field, a control field, an information field and a check field.
  • the address field, control field and information field are of variable length, but the check field has a fixed length defined by the protocol.
  • the information field is simply defined as those octets that follow the control field and precede the check value.
  • a field is therefore an example of a defined location in the above sense, and a protocol will define that a specific number in a specific field is to be interpreted in a given way, i.e. the number has a specific meaning defined by the protocol.
  • modes of transmission reliability e.g. the above mentioned HDLC allows two modes of transmission reliability, namely the so called numbered mode (or I-mode) and the so called unnumbered mode (or UI-mode).
  • the sending peer performs retransmission of said packet. In this way it can be assured that all packets are correctly transmitted, although this can cause a delay in total transmission time, depending on how many packets have to be retransmitted.
  • the information on the correct receipt of packets will typically be communicated by means of acknowledgment messages from the receiving peer to the sending peer, and the precise flow control for the transmission and retransmission will usually be performed by using the concept of sliding windows (so-called window based flow control), according to which a sender may send out more than one packet before receiving a acknowledgment, i.e. does not have to wait for an acknowledgment for each packet before sending out the next one.
  • the unnumbered mode does not provide for retransmission. This means that packets are simply sent out in the given order, regardless of their being received correctly by the receiving peer. This mode has the advantage of faster transmission, but transmission reliability depends on the quality of the physical connection.
  • Transmission reliability is especially a problem in connections that comprise radio links.
  • the radio link protocol RLP is run. All known implementations of RLP are fixedly set to run in the numbered mode. In this way, the reliable transmission of data over a radio link, whose transmission quality can strongly fluctuate, is ensured. It is known to implement such systems as shown in FIG. 6 in such a way that the mobile station MS can request during connection set-up that no RLP be run (also referred to as a transparent circuit-switched GSM data service in the context of the example of FIG. 6 ). This reduces the transmission delay, but at the price of reduced transmission reliability.
  • This problem is not restricted to the RLP or to radio links, but basically occurs in any protocol that provides a reliability mode such as the above mentioned numbered mode.
  • RfC 2475 suggests classifying and marking packets to receive a particular per-hop forwarding behavior (PHB) on nodes along their path. Header information in the header of a packet belonging to a given protocol layer is used exclusively by implementations of said given protocol layer.
  • the differentiated services architecture is based on a model where traffic entering a network is classified and possibly conditioned at the boundaries of the network, and assigned to different behavior aggregates. Each behavior aggregate is identified by a single differentiated services (DS) codepoint.
  • DS differentiated services
  • Packet classifiers are described, which select packets in a traffic stream based on the content of some portion of the packet header.
  • the DS codepoint or DS field which belongs to the IP layer, is only used at the IP layer.
  • a behavior aggregate classifier is described, which classifies packets based on the DS codepoint only.
  • a multi-field classifier is described, which selects packets based on the value of a combination of one or more header fields.
  • a communication device for generating data packets to be sent out having a first data structure determined by a first predetermined protocol, which is arranged to receive data packets of a second structure determined by a predetermined second protocol and generating said data packets of said first structure by embedding each data packet of said second structure in one or more data packets of said first structure, and which comprises a discriminator means that is arranged to discriminate said data packet of said second structure according to predetermined rules, on the basis of the contents of said data packets of said second structure.
  • the implementation of a protocol is made sensitive to the type of data being sent, so that the setting of parameters relevant for the transmission can be adjusted automatically at the layer setting the parameters being adjusted in accordance with the contents of the packets to be sent.
  • the present invention can take into account that the data in packets being received from a higher layer in order to be encapsulated or segmented and sent further (either directly into the link or on to lower layer), may be classified into different categories with respect to the adjustable parameters, where the parameters can automatically be adjusted for the individual packet in accordance with the category into which is classified.
  • contents refers to any contents. It should be noted that the specific type of contents used for discriminating may therefore be data consciously added to the packet by the originator of the packet at a specific layer in view of the discrimination operation at a lower layer, i.e. there is a scheme through which higher layer peers may specify information to lower layer peers in order to influence operating modes at the lower layer, e.g. by using a predetermined field of the higher layer protocol, or the discrimination operation at the lower layer will be conducted independently and individually, i.e. without any active influence from higher layers, namely by parsing for data that does not carry the intention of conveying information to lower layers, e.g. the protocol ID in a header.
  • the present invention therefore develops a concept that basically contradicts the firmly established teaching that all layers must operate independently of one another.
  • the present invention makes the implementation of a given protocol at a given layer intelligent, such that it can flexibly and according its own determinations continuously set the parameters depending on what type of packets are to be sent.
  • the adjustable parameters relate to the reliability mode, such that the reliability mode (e.g. the numbered or unnumbered mode) is adjusted automatically at the layer performing the embedding, on the basis of the discrimination result.
  • the reliability mode e.g. the numbered or unnumbered mode
  • This preferred embodiment provides the advantage that data packets suitable for different transmission reliability modes can automatically be sent simultaneously between peers of the layer at which the present invention is applied. For example, if the present invention is applied to an implementation of the RLP that embeds PPP packets by segmentation, which in turn encapsulate packets of higher layers, such as IP and above that TCP or UDP, then the RLP implementation in accordance with the invention can discern the packets containing UDP packets and those containing TCP packets, and can e.g. send the UDP packets in the unnumbered mode and the TCP packets in the numbered mode at the RLP layer.
  • the embodiment relating to the setting of reliability modes is preferably applied to the implementation of the protocol at the link layer (e.g. RLP).
  • the classification into categories is preferably done by taking into account the transmission reliability provisions of the higher layer packets being classified.
  • the UDP packets were classified into a category such that they are sent in the unnumbered mode, which is advantageous, as the UDP itself does not provide for retransmission of corrupted packets.
  • TCP provides for retransmission.
  • PPP is used to transport multiple protocols, such as IP, LCP (link control protocol), PAP (password authentication protocol) etc. simultaneously over a serial link.
  • a PPP protocol identifier identifies which protocol data unit (PDU) or protocol packet is contained in a particular PPP packet.
  • IP which in turn is carried by PPP, can carry packets of multiple protocols, namely TCP, UDP and ICMP (Internet Control Message Protocol), which are also distinguished by a protocol identifier in the IP header.
  • TCP protocol data unit
  • UDP User Data Identifier
  • ICMP Internet Control Message Protocol
  • signaling messages such as LCP or PAP should be carried in the numbered mode
  • real-time data streams e.g. voice information for an Internet-telephone conversation sent in UDP packets
  • the present invention solves this conflict, because according to the invention the RLP implementation will automatically send the LCP messages in the numbered mode, whereby safe PPP link establishment is ensured, and then send following PPP packets containing UDP packets in the unnumbered mode, so that these are not unnecessarily delayed. Moreover, not only can such a conflict between different kinds of packets sent at different times during one connection be solved, but the present invention also allows two conflicting streams (in terms of reliability) to be sent in parallel, e.g. the above mentioned UDP data stream together with the TCP packets.
  • the embodiment relating to the setting of reliability modes can be applied to any implementation of a protocol that allows for two or more reliability modes. For example, it can also be applied if LLC (Logical Link Control) packets are to be sent over a RLC (Radio Link Control) link. Equally well, the place of implementation is naturally not restricted to the above example of FIG. 6, but will be wherever it is suitable or desirable for the given protocol. For example, in a General Packet Radio Service (GPRS), it would be the TAF and the GSN (GPRS Support Node).
  • GPRS General Packet Radio Service
  • ARQ Automatic Repeat request
  • the possible modes are naturally not restricted to only two, i.e. unreliable (UI-mode) and reliable (I-mode), but may also have a larger number, such as there being a semi-reliable mode in addition to the UI-mode and I-mode, said semi-reliable mode being a combination of the two others with in-sequence-delivery or out-of-sequence delivery.
  • FCS Fibrevity
  • FEC Forward Error Control
  • the invention is applicable to the transmission scheme of interleaving-based error prevention with the operating modes of e.g. using one of two or more interleaving schemes.
  • the invention is applicable to the transmission scheme of power control with the operating modes of e.g. using one of two or more power levels.
  • the invention is applicable to the transmission scheme spreading-based error prevention (in spread-spectrum technologies such as CDMA) with the operating modes of e.g. using one of two or more spreading factors.
  • the invention is applicable to the transmission scheme of frame length control with the operating modes of using e.g. one of two or more possible frame lengths.
  • the invention is applicable to the transmission scheme of bandwidth reservation control with the appropriate operating modes such as the allocation of 1, 2, 3, . . . or 8 time slots e.g. in the
  • An important advantage of the present invention lies in the fact that it in principal does not require the alteration of any protocols, but only of its peer implementations, so that it can be applied universally in any appropriate context without compatibility or transition problems.
  • the present invention is applied to provide a way of transmitting packets at a lower layer in accordance with transmission quality requests (such as QoS (Quality of Service) requirements and/or transmission priorities) specified by peers of a higher layer, where the packets or data units of said higher layer are embedded at said lower layer.
  • the peers of the higher layer use the packets of said layer as a vehicle for conveying said quality requests to the lower layer, i.e. there is a standardized scheme by which said quality requests can be understood by implementations of both layers. As an example, this can be done by using a predefined field in the header of the higher layer packets and standardizing the contents of said field.
  • a type of control channel is provided for conveying quality requests from the higher layer to the lower layer.
  • Said quality requests are not only used to map higher layer packets or flows (a flow is a uniquely identifiable stream of packets) to operating modes provided for the transmission at the lower layer, but also to dynamically adapt the operation modes themselves, at least in part on the basis of said quality requests.
  • the transmission quality requests are a type of control information that may be used as a quality command for letting the higher layer set a specific operating mode at the lower layer, or may be used by the lower layer implementation liberally such that the lower layer implementation chooses the operating mode for a given packet carrying said quality request on the basis of said quality request, but the higher layer has no direct influence on which mode the lower layer will choose.
  • FIG. 1 is a block diagram showing an embodiment of a communication device according to the present invention
  • FIG. 2 is a flow chart showing an embodiment of a method according to the present invention.
  • FIG. 3 is a schematic diagram for explaining the concept of protocol layering in terms of the example of the TCP/IP suite
  • FIG. 4 is a schematic diagram for explaining the flow of packets through the layers shown in FIG. 3;
  • FIG. 5 is a schematic diagram showing the concept of encapsulation in the subsequent protocol layers of FIG. 3 and FIG. 4;
  • FIG. 6 shows a schematic example of a connection between two IP-hosts over a circuit-switched GSM link, and the corresponding hierarchy of layers and protocols;
  • FIG. 7 shows the basic structure of a HDLC frame
  • FIG. 8 is a block diagram of a preferred embodiment of the device according to the present invention.
  • FIGS. 9 a and 9 b are a flow chart showing a preferred embodiment of the method of the present invention.
  • FIG. 10 shows a communication arrangement for explaining another preferred embodiment of the invention.
  • the present invention will be described by way of embodiments relating to the setting of transmission reliability modes. As already mentioned, this is a preferred application of the invention and serves well to illustrate the invention. However, the invention is generally applicable to the setting of any kind of adjustable parameter, e.g. also to the setting of security modes.
  • a communication device that is constituted by the implementation of a communication protocol of layer n receives packets from a higher layer (n+1), such that these packets may be embedded into packets of the layer n.
  • n+1 a higher layer
  • the term “embedding” comprises both encapsulation and segmentation. It should be remarked that the entire introductory portion of the present application is incorporated into the disclosure of the invention, to thereby avoid unnecessary repetitions.
  • the protocol of layer n could be RLP and the packets of layer (n+1) could be PPP frames, in which case the embedding would consist in the segmentation of one PPP frame or packet into a plurality of RLP packets. It may be remarked that a PPP frame will typically have a length of 1500 byte, whereas a RLP frame will typically have a length of 30 byte.
  • the protocol of layer n is PPP and the protocol of layer (n+1) is an appropriate higher layer protocol, such as one of the protocols shown in FIG. 5, in which case the embedding would be done by encapsulation.
  • this embodiment has a discriminator 1 that receives the packet of layer (n+1), where said discriminator discriminates the received packet according to predetermined rules of classification.
  • An example of this could be, in the case that the packets of layer n are PPP frames, to check the individual headers of the received PPP frame to thereby determine what type of information is being transported by said frame, and then accordingly classifying the frame. For example, if the frame is carrying LCP information, then it may be classified into the category “reliable transport”, and if it is carrying UDP information, then it may be classified into the category “reliability not required”.
  • the result of the discrimination i.e. the classification is conveyed to a control means 2 that in turn controls an embedding means 3 with a transmission reliability setting command.
  • the discriminator passes the packet to be embedded on to the embedding means 3 , where it is embedded into one or more packets of layer n and the transmission reliability mode, which is appropriately set in each packet of layer n, e.g. by a corresponding flag, is set in accordance with the transmission reliability setting command.
  • the thus generated packets of layer n are then appropriately passed on to the next stage of processing.
  • This next stage of processing depends on the specific application, and can therefore be chosen in any desirable or required way. For example, if the packets of layer n are intended to directly go to a next lower layer of (n ⁇ 1) (not shown in FIG. 1 ), then it is possible that the packets of layer n will simply be passed to an input buffer of the next layer.
  • the packets if e.g. the packets are intended to be sent over an established link, then they will be preferably placed in an output buffer, which is appropriately controlled in accordance with the given situation. The precise method of flow control from such an output buffer depends on the specific application, e.g. the given protocol of layer n and on the specific link.
  • the present invention is highly flexible in that it can be applied to any protocol implementation that embeds packets of one layer in packets of another and which provides for at least two different reliability modes.
  • FIG. 2 shows a flow chart that embodies the method of the present invention.
  • a first step S 1 it is determined if a higher layer protocol packet has been received or not. If such a packet has been received, then the process proceeds to step S 2 , in which the received packet is discriminated according to predetermined rules of classification. Then in step S 3 the received packet is embedded into one or more packets of the given layer (e.g. n in FIG. 1) and the transmission reliability mode in each of said packets is set in accordance with the discrimination result. Finally, the embedded packets are passed on to the next stage, where the process shown in FIG. 2 sends said packets to an output buffer in step S 4 for being sent out.
  • the process shown in FIG. 2 sends said packets to an output buffer in step S 4 for being sent out.
  • FIG. 8 A system corresponding to what is shown in FIG. 1 and having an input and an output buffer is shown in FIG. 8 .
  • the device of FIG. 8 also has a discriminator 1 , a control means 2 and an embedding means 3 , and additionally an input buffer 4 and an output buffer 5 are shown, which are also both connected to and controlled by the control means 2 .
  • the operation is similar to that explained in connection with FIG. 1, only that the packets of layer n are provided to the discriminator 1 via the input buffer 4 , where the control means 2 performs an appropriate control for letting the input buffer 4 pass packets to the discriminator 1 , and in that FIG. 8 shows an example, in which the embedding means 3 passes the packets of layer n to an output buffer, which sends said packets of layer n out under control of the control means 2 .
  • the present invention is flexible in that any appropriate method of flow control can be chosen.
  • two transmission reliability modes such as the above described numbered and unnumbered mode
  • respective packets of layer n can be placed into separate queues in the output buffer 5 .
  • the output buffer 5 will contain two queues. If these reliability modes are the numbered and unnumbered mode, then the output buffer will have a queue for packets of the numbered mode and a queue for packets of the unnumbered mode.
  • one embodiment of this system shown in FIG. 8 can consist in the output buffer 5 carrying a respective queue for each transmission reliability mode into which packets are discriminated by the discriminator 1 . Then the packets in the individual queues can be handled in any appropriate or desired way, e.g. there can be a predetermined priority order for the individual queues (i.e. the individual reliability modes).
  • a predetermined priority order for the individual queues i.e. the individual reliability modes.
  • An example of this in an implementation having only a numbered and an unnumbered mode, could be that there is no basic priority order between numbered and unnumbered packets for first packets to be sent (these packets are treated in a FIFO manner regardless of which queue they belong to), but that numbered packets that are to be retransmitted receive a higher priority and are consequently preferably transferred.
  • the flow control of packets from the numbered mode queue can be conducted in accordance with the known window-based flow control, whereas the flow control from the unnumbered mode queue can be done by simply sending these packet
  • FIGS. 9 a and 9 b A preferred embodiment for the method of the present invention is shown in FIGS. 9 a and 9 b . Steps corresponding to those already discussed in connection with FIG. 2 carry the same reference numerals.
  • the method shown in FIGS. 9 a and 9 b relates to a case in which the invention is applied to the implementation of a protocol, where said protocol provides a numbered reliability mode (I-mode) and an unnumbered reliability mode (UI-mode).
  • I-mode numbered reliability mode
  • UI-mode unnumbered reliability mode
  • step S 1 it is determined if a higher layer packet has been received. If yes, then the process proceeds to step S 21 , in which the protocol ID in the header of the received higher layer packet is analyzed. For example, if the higher layer packet received is a PPP frame as shown at the bottom of FIG. 5 , then the process will simply check the PPP header directly following the start flag. Then, in step S 22 it is determined if the identified protocol ID is associated with the numbered mode, said association being given by the above mentioned predetermined rules.
  • step S 22 the process determines that LCP information is being transported, then the procedure branches to step S 31 , in which the received higher layer packet is embedded into one or more packets of the layer at which the present invention is implemented, where the reliability mode in each of said one or more packets is set to the numbered mode, e.g. by setting the corresponding reliability mode flag in each packet.
  • step S 23 determines if the identified protocol ID is associated with the unnumbered mode. If this is the case, then the process proceeds to step S 32 , in which the received higher layer packet is embedded into one or more packets of the layer at which the present invention is implemented, and the reliability mode in each of said one or more packets is set to the unnumbered mode, e.g. by setting the appropriate flag. If both steps S 22 and S 23 lead to a negative result, then step S 24 specifies that the check proceed up one protocol layer in the received packet, such that the next header be checked. When again looking at the example at the bottom of FIG.
  • the process then repeats the steps S 21 to S 24 . If the determined protocol ID can again not be allocated to either the numbered mode or the unnumbered mode, then the process again goes up one protocol layer, e.g. in the example of FIG. 5 to the TCP header.
  • the association between given protocol packets and the numbered mode or unnumbered mode will be stored in a table that is looked up during the decision steps S 22 and S 23 .
  • a fail-safe mechanism into the process shown in FIGS. 9 a and 9 b , e.g. a counter in step S 24 that only allows a moving up to a next protocol layer for a predetermined number of times, where the exceeding of said predetermined number of times leads to a default mode being assigned to the received packet in question.
  • This default mode can be either the numbered mode or the unnumbered mode.
  • other fail-safe mechanisms are possible, and can be chosen in any desired or required way.
  • step S 31 or S 32 the process proceeds to step S 4 , in which the packets are passed to the output buffer, just as in the case of FIG. 2 .
  • the process then turns to step S 1 to wait for the next higher layer packet to be received.
  • the method of FIG. 9 embodies a system in which the data packets have one or more sections carrying information on the contents of the packet (e.g. a packet encapsulating a hierarchy of protocols), and the discriminator means is arranged to analyze said one or more sections to thereby discriminate the data packets in accordance with their contents. More specifically, said one or more sections are packet headers associated with respective protocol layers and containing protocol identification information identifying the protocol with which the contents of the packet are associated.
  • the packet headers form a hierarchy in accordance with the protocol layers, and, for a packet to be discriminated, the discriminator is arranged to first determine the protocol identification in the header associated with the first higher layer protocol and then compare said protocol identification with stored rules that allocate a predetermined transmission reliability mode to predetermined protocol identifications. Furthermore, the discriminator is arranged to set the transmission reliability mode for said packet to be discriminated in accordance with a determined allocation if said protocol identification is among the stored rules, and if said protocol identification is not among the stored rules, then determine the protocol identification in the header associated with the next protocol one layer up in the hierarchy and then compare said protocol identification of said next protocol with said stored rules that allocate a predetermined transmission reliability mode,
  • the present invention is applied to the implementation of protocols that use segmentation for embedding higher layer packets into the packets to be sent over a link, and said protocols support two transmission reliability modes, namely a numbered mode and an unnumbered mode.
  • protocols are protocols for handling communication over radio links, such as the above mentioned RLP and RLC.
  • the invention then not only has specific features for embedding packets to be sent, but also comprises specific features relating to the receipt of such embedded link layer protocols from a sending peer, i.e. features that relate to the implementations properties as a receiving peer.
  • the RLP sender analyses the data stream being passed to it from a higher layer, e.g. the PPP frames, to determine in which mode each higher layer frame is to be sent, i.e. in the numbered mode or unnumbered mode. This process will be done as described in connection with FIGS. 8 and 9, such that a repetition is not necessary here.
  • the flow control of packets from the output buffer is performed such that RLP packets in the numbered mode and unnumbered mode are sent out on a FIFO basis with respect to the first sending (of numbered mode packets, because unnumbered mode packets are always only sent once), but RLP packets of the numbered mode that are to be retransmitted have a higher priority and are therefore always sent as soon as possible.
  • the RLP receiver separates the packets of the unnumbered mode and numbered mode into respective and distinct buffers or at least distinct queues. Like the RLP sender, the RLP receiver always analyses the data in each buffer to thereby discriminate higher layer frames. Only once a complete higher layer frame has been received, will it be released to the higher layer on the receiving side. A problem may occur for packets sent in the unnumbered mode, because in such packets the delimiter (e.g. start or end flag) for the higher layer packet may get corrupted during the transmission, as no retransmission takes place.
  • the delimiter e.g. start or end flag
  • the RLP receiver is adapted to employ a fixed buffer limit for packets of the unnumbered mode, beyond which packets of the unnumbered mode will be released to the next higher layer regardless if a delimiter has been received or not. More specifically, after the fixed buffer limit is exceeded, the RLP receiver will release every RLP packet of the unnumbered mode to the next higher layer until another higher layer packet delimiter has been detected. Using said higher layer packet delimiter as a new starting point, the RLP receiver can then again wait for the next higher layer packet delimiter, i.e. until the next complete higher layer packet has been received.
  • Another mechanism for enabling the RLP receiver to distinguish the individual higher layer packets is to have the RLP sender duplicate every higher layer delimiter it detects in the data that it sends out.
  • the RLP sender will also look for the delimiters of the next higher layer, e.g. PPP, and always insert an identical delimiter next to each delimiter it detects. It is advantageous if the above mentioned process in response to a fixed buffer limit being exceeded is retained in the receiving features of the RLP implementation, i.e. if the feature of delimiter duplication by the implementation of the sender is combined with buffer limit feature relating to the implementation of the sender.
  • the sender features are again as described above, namely the sender analyses the data stream it receives to determine in which mode each higher layer frame is to be sent, i.e. in the numbered mode or unnumbered mode. Flow control from the output buffer is conducted in such a way that retransmitted numbered mode packets always have a higher priority.
  • the receiver is able to separate the numbered mode and unnumbered mode packets it receives into distinct buffers or queues, just as in the previously explained case. Now, the receiver only analyses numbered mode packets to discriminate higher layer packets (e.g. PPP frames).
  • the receiver immediately releases numbered mode and unnumbered mode packets to the higher layer, with the usual restriction that numbered mode data can only be released in the correct order.
  • Another exception is explained in the following.
  • numbered mode packets followed by unnumbered mode packets are being transmitted (for example a TCP session followed by a UDP session, or a UDP and TCP session that run in parallel), where a problem can occur, if numbered mode packets have to be retransmitted and unnumbered mode packets are being received in the meantime.
  • the following mechanism may be used. As long as the higher layer packet which was sent in the numbered mode has not been completely received (e.g. because the packet which contains the PPP frame delimiter marking the end of a TCP packet has to be retransmitted) the unnumbered mode packets have to be buffered. The buffer will not be released to the higher layer before the whole numbered mode packet has been received and released. After the numbered mode packet has been completely received and released to the next higher layer, the contents of the buffer containing unnumbered mode packets is released. Then normal operation continues.
  • the higher layer packet which was sent in the numbered mode has not been completely received (e.g. because the packet which contains the PPP frame delimiter marking the end of a TCP packet has to be retransmitted) the unnumbered mode packets have to be buffered. The buffer will not be released to the higher layer before the whole numbered mode packet has been received and released. After the numbered mode packet has been completely received and released to the next higher layer, the contents of the buffer containing unnumbered mode packet
  • the receiver additionally has knowledge or information on which packet delimiter is being used.
  • the default delimiter should be the delimiter of the usual packets of the next higher layer (e.g. the PPP frame delimiter), but if another delimiter shall be used, this can be negotiated between the two link layer entities, i.e. the two RLP peers. This in other words means that other protocol packets of the next higher layer could be processed, i.e. those of more than one protocol. In the context of the above example relating to PPP frames being embedded in RLP packets, this means that the RLP implementation could then not only embed PPP frames but frames of other protocols as well, where said other protocols belong to the same layer as PPP.
  • the receiver implementation will not be changed in any way.
  • the receiver will always release unnumbered mode packets when received and the delivery of numbered mode packets is as usual released in order. Therefore it is up to the sender to make sure that the higher layer packets (e.g. PPP frames) will be released correctly at the receiver. This can be done in such a way that before the sender starts an unnumbered mode session, no unacknowledged numbered mode packet is allowed to be outstanding, i.e. all numbered mode packets have to be acknowledged by the receiver.
  • this mechanism is simpler to implement, as it does not change the receiving features, it results in an extra delay introduced when switching between a numbered mode session and an unnumbered mode session.
  • Another mechanism could consist in controlling the output buffer of the sender in such a way that when an unnumbered mode session is being run by the sender, all unnumbered mode packets to be sent should be sent in consecutive RLP frames carrying the unnumbered flag.
  • the invention was described with regard to discriminating with respect to a specific field in the packet header of a packet being embedded, namely the protocol ID field of higher layers, and with respect to the specific transmission scheme of ARQ-based error recovery, using the two operating modes relating to reliability, namely the numbered mode and the unnumbered mode.
  • the invention is by no means restricted thereto.
  • the invention may equally well be applied to discriminating with respect to any packet content in any part of a packet, such as also the above mentioned DS field or IP option.
  • any packet content in any part of a packet such as also the above mentioned DS field or IP option.
  • the operating modes associated with ARQ naturally more than two may be employed, such as e.g. the alraedy mentioned numbered and unnumbered mode supplemented by a mixed mode.
  • FCS Fibrevity
  • FEC Forward Error Control
  • the invention is applicable to the transmission scheme of interleaving-based error prevention with the operating modes of e.g. using one of two or more interleaving schemes.
  • the invention is applicable to the transmission scheme of power control with the operating modes of e.g. using one of two or more power levels.
  • the invention is applicable to the transmission scheme spreading-based error prevention (in spread-spectrum technologies such as CDMA) with the operating modes of e.g. using one of two or more spreading factors.
  • the invention is applicable to the transmission scheme of frame length control with the operating modes of using e.g. one of two or more possible frame lengths.
  • the invention is applicable to the transmission scheme of bandwidth reservation control with the appropriate operating modes such as the allocation of 1, 2, 3, . . . or 8 time slots e.g. in the
  • the discriminating may be conducted in view of generalized operating modes that consist e.g. of a combination of ARQ-related mode and power control related mode, such for example the numbered mode, the unnumbered mode, and 4 power levels are combined to achieve 8 modes, i.e. (I-mode, power level 1 ), (I-mode, power level 2 ), . . . , (UI-mode, power level 4 ).
  • generalized operating modes consist e.g. of a combination of ARQ-related mode and power control related mode, such for example the numbered mode, the unnumbered mode, and 4 power levels are combined to achieve 8 modes, i.e. (I-mode, power level 1 ), (I-mode, power level 2 ), . . . , (UI-mode, power level 4 ).
  • I-mode power level 1
  • I-mode power level 2
  • UI-mode power level 4
  • the present invention is applied to provide a way of transmitting packets at a lower layer in accordance with transmission quality requests such as QoS (Quality of Service) requirements and/or transmission priorities specified by peers of a higher layer, where the packets or data units of said higher layer are embedded at said lower layer.
  • transmission quality requests such as QoS (Quality of Service) requirements and/or transmission priorities specified by peers of a higher layer, where the packets or data units of said higher layer are embedded at said lower layer.
  • L3 will be used to refer to a network layer protocol, e.g. IPv4 or IPv6, also see FIG. 3 .
  • the L3 protocol data unit (PDU) will be referred to as a packet, and the PDU header as a packet header.
  • L1/L2 will be used to refer to a protocol or a set of two or more protocols below L3, such as the physical and/or the link layer of a specific network, again see FIG. 3 .
  • bearer will be used for an L1/L2 with either fixed settings for all L1/L2 operating modes or fixed QoS (Quality of Service) settings to which all L1/L2 operating modes are dynamically adapted depending on the momentary conditions of the medium underlying, L1/L2 (e.g.
  • peers will be used as above, i.e. as relating to processes that communicate according to a common protocol of a certain layer. Examples are a WWW client and server communicating according to the HTTP protocol on the application layer, or a TCP sender and receiver on the transport layer, also see FIG. 6 .
  • peer will always refer to peers which communicate according to protocols which are directly or indirectly based on L3.
  • flow will refer to a single instance of peer-to-peer L3-packet-based (packet-switched) traffic which is identified by source address, source port, destination address, destination port and protocol ID. In other words, a flow is a uniquely identifiable stream of packets. Each flow is considered as having certain QoS requirements. QoS requirements may vary over time.
  • a peer e.g. a legacy WWW browser chooses the QoS requirements for its flow, this also comprises that some other process does this on behalf of the peer.
  • FIG. 10 shows a communication between a mobile IP-host suitably linked (in FIG. 10 over a so called bluetooth link) to a mobile telephone adapted to transport IP packets.
  • the telephone in turn can establish a radio link with a wireless access network, where any suitable communication standard can be used, such as e.g. GSM, GPRS or W-CDMA.
  • the wireless access network is connected to the Internet, which comprises a multitude of hosts, two of which are shown in FIG. 10 .
  • Peers A. 1 and B. 1 are shown as examples on the mobile side, and peers A. 2 and B. 2 as their respective counterparts. These peers may pass QoS requirements and/or transmission priorities, i.e. in general quality requests as control information, to the L3 layer.
  • the peers are either L3 peers or of protocol layers above L3. This can be done by specifying a given field in the L3 header as relating to quality requests, such that the L3 layer is used as a level through which peers express their QoS requirements and/or priorities on a per flow or per packet basis.
  • the discrimination of L3 packets is handled by a controller or controlling process 11 at each side of L1/L2, which in turn controls an adapter or adaptation process 12 in response to the discrimination result.
  • the controlling process 11 “reads” the per packet QoS requirements and/or priorities and maps them to respective L1/L2 operating modes and/or priorities of that network.
  • the adaptation process 12 is capable of adapting the L1/L2 operating modes on a per packet basis and makes this decision at least in part dependent on the information provided by the controller. Typically, the adaptation of the L1/L2 operating modes will also be conducted on the basis of measured conditions of the medium underlying L1/L2.
  • the present embodiment comprises dynamically adapting L1/L2, where L1/L2 is adaptable on a per packet basis, and having a control process which has access to the per flow/packet QoS requirements and/or priorities and which can use those to control the adaptation process and/or the L1/L2 scheduler(s) accordingly.
  • the optimal adaptation of L1/L2 for TCP would use ARQ-based error recovery in I-mode and other transmission schemes, e.g. FEC to be optimized for highest throughput.
  • the controller can make the appropriate decision, e.g. for a mobile-terminated TCP flow.
  • the optimal adaptation for a real-time VoiceOverIP flow e.g. broadcast radio which does not have a session initiation protocol
  • the controller can make the appropriate decision, e.g. for a mobile-terminated real-time VoiceOverIP flow.
  • L1/L2 of state-of-the-art networks e.g. wireless networks
  • L1/L2 of state-of-the-art networks cannot be adapted down to the level of exactly meeting the QoS requirements of individual flows, and also not one step further down to the level of meeting the QoS requirements of individual packets of a flow.
  • the latter could e.g. be required for flows which have QoS requirements that vary over time so that different packets of the same flow have different QoS requirements.
  • state-of-the-art networks can at most only support one or more bearers simultaneously.
  • the way that flows are mapped onto those bearers is not directly related to the QoS requirements of those flows but is based on criteria like priorities, which e.g. correspond to network operator charges per packet (as e.g. done in the GPRS communication system).
  • the resulting problem is that either the QoS requirements of some Flows/packets are not met, or the QoS requirements of some flows/packets are met but only in a non-optimal way (e.g. the FEC scheme chosen for a TCP window flow is too strong providing a lower bit rate than could have been provided with the optimal FEC scheme), or the QoS requirements of some flows/packets are exceeded, which corresponds to wasted network resources (e.g. spectrum or transmission power).
  • wasted network resources e.g. spectrum or transmission power
  • L1/L2 adaptation of L1/L2 to the QoS requirements of flows is independent of the concept of priority-based traffic scheduling.
  • a real-time voice stream will have specific QoS requirements independent of whether it is assigned to the best-effort or some kind of predictive QoS traffic class.
  • the present embodiment solves this problem by dynamically adapting L1/L2 to the QoS requirements of each flow or packet. It provides the following functionalities and their interworking:
  • functionality 1 a standardized scheme through which the QoS requirements for individual flows/packets can be uniquely specified so that the semantics are the same in any network supporting that scheme;
  • functionality 2 an adaptation process which can adapt L1/L2 according to operating modes provided by a control process.
  • the operation modes can either be provided explicitly or implicitly in a form that only has local semantics, e.g. with respect to QoS which are specific for the network of that L1/L2.
  • the adaptation process can combine the operating modes provided by the control process with measurement information about conditions of the medium (e.g. radio) underlying L1/L2 to eventually decide on the final operating mode. This is however only an implementation detail;
  • functionality 3 a control process which is capable of controlling the adaptation process on a per flow/packet basis given the QoS requirements of each flow/packet by having access to the control channel;
  • functionality 4 a control channel through which the per flow/packet QoS requirements can be made available to the control process.
  • adaptation and the control process each can either be distributed processes, e.g. one process per L1/L2 transmission scheme, or a single process adapting/controlling all L1/L2 transmission schemes. This is again an implementation detail. It may also be noted that the above described functionalities require an L1/L2 which can be adapted on a per packet basis or at least on a per packet sequence basis, e.g. it must be possible to change the FEC from one packet to the other or at least from one sequence of packets to the other.
  • RfC 2475 does not hint at dynamically adapting L1/L2. Moreover, it is not known from the prior art to implement L1/L2 to be adaptive with respect to QoS requirements of individual packets/flows (functionality 2 ), and it is not known to provide the control process of functionality 3 .
  • peers A. 1 , B. 1 , A. 2 and B. 2 from FIG. 10 as a n example (i.e. without the features of the invention)
  • peers that are physically close e.g. A. 1 and B. 1
  • L1/L2 in GSM-CSD and GPRS have a direct control channel to adapt that L1/L2 according to QoS which are explicitly known to that peer (or a process that acts on its behalf).
  • peers A. 1 and B. 1 could have access on an AT command interpreter through which it can be chosen to run a reliable link layer protocol (RLP) or not to do so (transparent or non-transparent mode).
  • RLP reliable link layer protocol
  • peers A. 2 and B. 2 would have no way of adapting different L1/L2s for a TCP-flow they initiate. There is also no control process (functionality 3 ) which could perform the adaptation on behalf of peer A. 2 and/or B. 2 .
  • GSM-CSD is only capable of operating according to fixed modes (e.g. FEC scheme x and I-mode error recovery) for the duration of the circuit switched call, although several flows with potentially different QoS requirements may have to be transported simultaneously.
  • fixed modes e.g. FEC scheme x and I-mode error recovery

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Transmitters (AREA)

Abstract

In the present invention, the implementation of a protocol that embeds packets is made sensitive to the type of data being embedded, so that adjustable parameters can be set automatically at the layer providing the parameters being adjusted in accordance with the packets being embedded. Thus it is taken into account that the data in packets being received from a higher layer in order to be encapsulated or segmented and sent further (either directly into the link or on to lower layer), may be classified into different categories with respect to the adjustable parameters, where the parameters can automatically be adjusted for an individual packet in accordance with the category into which is classified.

Description

FIELD OF THE INVENTION
The present invention relates to a device and method for sending data packets, for example over a link establishing a connection between a computer and a packet exchange network such as the so called Internet.
BACKGROUND OF THE INVENTION
With the progress in data processing and communications technology over the past years, the establishment of data exchange networks has become an important fixture in many aspects of the modern world, e.g. in the scientific and military community, but also with strongly increasing growth in the business and private realm. The best example of this is the steadily rising offer and demand of services in the world wide communication network commonly referred to as the Internet. In principle, the term “internet” simply refers to a network consisting of other networks, so that the world wide “Internet” is only an example, albeit a very well known one.
The commonly used data exchange principle for networks is that of packet exchange. This means that the data to be sent is broken down into units. Rules for sending and receiving such units, as well as rules for the structure of the units themselves are determined by so called protocols. Protocols are sets of rules that allow the communication between a sending end and a receiving end, as the rules specify how and in what form data to be sent has to be prepared, such that the receiving end may interpret the data and react in accordance to protocol defined rules to which both partners in the communication adhere.
An important concept for allowing the exchange of data between different networks, and thereby between numerous kinds of software and hardware, is that of protocol layering. This means that a number of protocols (sometimes also referred to as a suite) is organized in a hierarchy of layers, where each layer has specific functions and responsibilities. This will briefly be explained by referring to an example illustrated in FIGS. 3 to 5. A more detailed description of this concept is e.g. given in “TCP/IP Illustrated, Volume 1, The Protocols” by W. Richard Stevens, Addison-Wesley, 1994.
The Transmission Control Protocol (TCP) and the Internet Protocol (IP) are examples of protocols according to which communication over the Internet may be handled. What is commonly referred to as TCP/IP, however, comprises other protocols as well. The so-called TCP/IP suite has four layers, as shown in FIG. 3. The link layer handles the input and output of data into the physical communication media, e.g. a cable or a radio connection. It typically is implemented in the device driver in the operating system and the corresponding network interface card in the computer. The network layer handles the movement of packets around the network, e.g. routing. IP is an example of a network layer protocol. The transport layer provides a flow of data for the application layer above. For example, TCP is at the transport layer. An alternative to TCP is the User Datagram Protocol (UDP). The application layer is constituted by the application program sending or receiving data, e.g. an e-mail program.
A communication between two points then has the schematic form shown in FIG. 4. Data is first handed down through the layers and input into the physical connection on the sending side, and then handed up through the layers on the receiving side. This is indicated by the solid line arrows. The elements handling the data at a given layer in accordance with a protocol specified for that layer (e.g. TCP at the transport layer in the example of FIG. 4) are also referred to as peers. In other words, the transport layer in the example of FIG. 4 is handled by a TCP peer. It should be noted that the physical connection shown at the bottom of FIG. 4 may again consist of one or more protocol layers of its own, depending on the type of connection. This will be explained in more detail further on.
FIG. 5 illustrates the mechanism of passing data through the layers. The typical basic structure of a packet has two parts, namely a header and a payload part. The header contains information on the type of data contained in the payload part and communication control information for the respective layer. As can be seen in FIG. 5, at the application layer user data is processed by adding a header. The resulting data unit or packet is passed to the transport layer, where e.g. a TCP header is added. This TCP header contains information for the TCP peer on the receiving side. The resulting packet is sometimes also referred to as a TCP segment. Then this TCP segment is passed to the network layer, where in the example of FIG. 5 an IP header is added that e.g. contains routing information. The resulting packet is also referred to as an IP datagram. Finally, the IP datagram is passed to the link layer, where a header associated with the link layer protocol (LLP), e.g. the Point-to-Point Protocol (PPP), is added. The resulting packet is often called a frame. The frame also receives a start flag and an end flag, such that a receiver may recognize where a frame begins and where it ends. This process of embedding a packet of a higher layer in a larger packet of a lower layer is referred to as encapsulation.
On the receiving side, the user data is extracted by steps of de-encapsulation in the opposite order of what is shown in FIG. 5. It should be noted that the above description only refers to an example, and variations are possible. For example, some protocols not only add headers, but also trailers.
It should be remarked that a packet need not originate from the application layer, much rather a lower layer may generate a packet, e.g. for sending specific information regarding only that layer to the corresponding peer at the receiving end. An example of this is the sending of Link Control Protocol (LCP) packets prior to sending higher layer data, where said LCP packets are used by the link layer peers to configure the (physically established) link in accordance with parameters that are adjustable and/or negotiable at the link layer.
The representation in FIG. 4 is only very schematic, as it implies that the four individual peers on each side are respectively implemented in one location. This is possible, but in reality the situation is usually more complicated. FIG. 6 schematically shows an example of a communication between an IP-host 1 and an IP-host 2. The top part of the figure represents the physical communication path, and the lower part of the figure shows the logical communication path associated with the various protocols employed. The example of FIG. 6 relates to a connection to the Internet via a GSM network.
IP-host 1 can e.g. be a laptop computer. The terminal adaptation function TAF can be fulfilled e.g. by a PCMCIA interface card that is connected to the mobile station MS, e.g. a cellular telephone. The mobile station MS communicates with a base transceiver station BTS, which in turn is connected to a base station controller BSC. The connection to a public switched telephone network PSTN is accomplished by a modem in the interworking function IWF of the mobile switching center MSC associated with the base transceiver station BTS. It may be noted that due to the fact that GSM is digital, the TAF is not a modem. Finally, the PSTN provides the connection to an Internet services provider ISP, who in turn provides a gateway to the Internet. The physical connection between the Internet and IP-host 2, e.g. a personal computer to which an e-mail from IP-host 1 is to be sent, is not shown.
As can be seen in the lower part of FIG. 6, a TCP peer, an IP peer and a PPP peer are implemented at IP-host 1. The corresponding TCP peer and an IP peer reside in IP-host 2, whereas an IP peer and PPP peer are implemented at the Internet services provider ISP.
An important aspect of the layering scheme is that the different layers are “transparent”. This means that the peers in a layer are oblivious to what happens in another layer. As an example, the PPP peers establish a pseudo-dedicated PPP connection between the IP-host 1 and the Internet services provider ISP. The two PPP peers operate independently of what type of physical connection is used, i.e. independently of which specific protocols are provided in lower layers. Equally, the PPP peers pass packets coming from higher layers transparently, i.e. with out regarding their contents.
In the example of FIG. 6, a forward error correction (FEC) layer and an interleave layer are provided between the mobile station MS and the base transceiver station BTS, a layer 2 relay (L2R) and a radio link protocol (RLP) connection are established between the terminal adaptation function TAF and the mobile switching center MSC, and V.42 and V.32 interfaces are established between the interworking function IWF and the Internet service provider ISP. All of these protocols are known and, except for RLP, will not be discussed further.
It should be noted that although the RLP is responsible for transporting data units from higher layers, this is not done by means of encapsulation, i.e. by one higher layer data unit being fit into one lower layer data unit, much rather RLP performs segmentation, i.e. one higher layer data unit is divided into a plurality of segments and each segment is placed into a lower layer data unit. In other words, the RLP data units are smaller than the higher layer data units (e.g. a PPP frame) they transport. The principle of placing data units of a higher layer in data units of a lower layer will be referred to as embedding in this description, which comprises both encapsulation and segmentation.
As can be seen from the above, packets associated with different protocols are sometimes referred to differently, e.g. frame, segment, datagram etc. For the purpose of clarity, the present description uses the term “packet” generically as meaning any data unit that has a defined syntax, and a data structure specified by a predetermined protocol. “Data structure” means that specific data at defined locations (addresses) has a specific meaning defined by the respective protocol. An example of this will be explained in connection with FIG. 7, in which a frame structure in accordance with the high-level data link control protocol (HDLC) is shown. HDLC is a very basic protocol, and e.g. PPP has adopted many of the basic features of HDLC.
FIG. 7 shows a HDLC frame that has an address field, a control field, an information field and a check field. In HDLC, the address field, control field and information field are of variable length, but the check field has a fixed length defined by the protocol. For example, the information field is simply defined as those octets that follow the control field and precede the check value.
A field is therefore an example of a defined location in the above sense, and a protocol will define that a specific number in a specific field is to be interpreted in a given way, i.e. the number has a specific meaning defined by the protocol.
Problem Underlying the Invention
With regard to the sending of packets, it is known to provide modes of transmission reliability, e.g. the above mentioned HDLC allows two modes of transmission reliability, namely the so called numbered mode (or I-mode) and the so called unnumbered mode (or UI-mode).
In the numbered mode, if it is determined that a sent packet was not correctly received by the receiving peer, then the sending peer performs retransmission of said packet. In this way it can be assured that all packets are correctly transmitted, although this can cause a delay in total transmission time, depending on how many packets have to be retransmitted. The information on the correct receipt of packets will typically be communicated by means of acknowledgment messages from the receiving peer to the sending peer, and the precise flow control for the transmission and retransmission will usually be performed by using the concept of sliding windows (so-called window based flow control), according to which a sender may send out more than one packet before receiving a acknowledgment, i.e. does not have to wait for an acknowledgment for each packet before sending out the next one. These principles of flow control are well known in the art, e.g. in the above mentioned book by Stevens, and do not need to be repeated here.
In contrast to the numbered mode, the unnumbered mode does not provide for retransmission. This means that packets are simply sent out in the given order, regardless of their being received correctly by the receiving peer. This mode has the advantage of faster transmission, but transmission reliability depends on the quality of the physical connection.
Transmission reliability is especially a problem in connections that comprise radio links. In the example of FIG. 6, the radio link protocol RLP is run. All known implementations of RLP are fixedly set to run in the numbered mode. In this way, the reliable transmission of data over a radio link, whose transmission quality can strongly fluctuate, is ensured. It is known to implement such systems as shown in FIG. 6 in such a way that the mobile station MS can request during connection set-up that no RLP be run (also referred to as a transparent circuit-switched GSM data service in the context of the example of FIG. 6). This reduces the transmission delay, but at the price of reduced transmission reliability.
This problem is not restricted to the RLP or to radio links, but basically occurs in any protocol that provides a reliability mode such as the above mentioned numbered mode.
Moreover, there generally appears the problem of choosing appropriate operating modes for the transmission of packets at a certain layer.
From the Request for Comments (RfC) 2475 by Blake et al., December 1998 (http://www.ietf.org/html.charters/diffservcharter.html), a proposal for an architecture for differentiated services is known. RfC 2475 suggests classifying and marking packets to receive a particular per-hop forwarding behavior (PHB) on nodes along their path. Header information in the header of a packet belonging to a given protocol layer is used exclusively by implementations of said given protocol layer. The differentiated services architecture is based on a model where traffic entering a network is classified and possibly conditioned at the boundaries of the network, and assigned to different behavior aggregates. Each behavior aggregate is identified by a single differentiated services (DS) codepoint. Packet classifiers are described, which select packets in a traffic stream based on the content of some portion of the packet header. As already mentioned, the DS codepoint or DS field, which belongs to the IP layer, is only used at the IP layer. A behavior aggregate classifier is described, which classifies packets based on the DS codepoint only. Also, a multi-field classifier is described, which selects packets based on the value of a combination of one or more header fields.
OBJECT OF THE INVENTION
It is the object of the present invention to generally provide a mechanism for implementations of protocols that solves the above problem and makes the control for choosing operating modes more efficient, e.g. enables a better relation between transmission reliability and transmission speed.
DESCRIPTION OF INVENTION
This object is solved by the device and method described in the independent claims, where a communication device is provided for generating data packets to be sent out having a first data structure determined by a first predetermined protocol, which is arranged to receive data packets of a second structure determined by a predetermined second protocol and generating said data packets of said first structure by embedding each data packet of said second structure in one or more data packets of said first structure, and which comprises a discriminator means that is arranged to discriminate said data packet of said second structure according to predetermined rules, on the basis of the contents of said data packets of said second structure.
Advantageous embodiments are described in the dependent claims.
According to the present invention, the implementation of a protocol is made sensitive to the type of data being sent, so that the setting of parameters relevant for the transmission can be adjusted automatically at the layer setting the parameters being adjusted in accordance with the contents of the packets to be sent. In other words, the present invention can take into account that the data in packets being received from a higher layer in order to be encapsulated or segmented and sent further (either directly into the link or on to lower layer), may be classified into different categories with respect to the adjustable parameters, where the parameters can automatically be adjusted for the individual packet in accordance with the category into which is classified.
The term contents refers to any contents. It should be noted that the specific type of contents used for discriminating may therefore be data consciously added to the packet by the originator of the packet at a specific layer in view of the discrimination operation at a lower layer, i.e. there is a scheme through which higher layer peers may specify information to lower layer peers in order to influence operating modes at the lower layer, e.g. by using a predetermined field of the higher layer protocol, or the discrimination operation at the lower layer will be conducted independently and individually, i.e. without any active influence from higher layers, namely by parsing for data that does not carry the intention of conveying information to lower layers, e.g. the protocol ID in a header.
The present invention therefore develops a concept that basically contradicts the firmly established teaching that all layers must operate independently of one another. In contrast to what is known, namely the possibility of having a higher layer set a specific parameter (e.g. reliability) at a lower layer when setting up the connection, the present invention makes the implementation of a given protocol at a given layer intelligent, such that it can flexibly and according its own determinations continuously set the parameters depending on what type of packets are to be sent.
According to a preferred embodiment of the present invention, the adjustable parameters relate to the reliability mode, such that the reliability mode (e.g. the numbered or unnumbered mode) is adjusted automatically at the layer performing the embedding, on the basis of the discrimination result.
This preferred embodiment provides the advantage that data packets suitable for different transmission reliability modes can automatically be sent simultaneously between peers of the layer at which the present invention is applied. For example, if the present invention is applied to an implementation of the RLP that embeds PPP packets by segmentation, which in turn encapsulate packets of higher layers, such as IP and above that TCP or UDP, then the RLP implementation in accordance with the invention can discern the packets containing UDP packets and those containing TCP packets, and can e.g. send the UDP packets in the unnumbered mode and the TCP packets in the numbered mode at the RLP layer.
As already indicated in this last example, the embodiment relating to the setting of reliability modes is preferably applied to the implementation of the protocol at the link layer (e.g. RLP). Also, the classification into categories is preferably done by taking into account the transmission reliability provisions of the higher layer packets being classified. In the above example, the UDP packets were classified into a category such that they are sent in the unnumbered mode, which is advantageous, as the UDP itself does not provide for retransmission of corrupted packets. By contrast, TCP provides for retransmission. By applying the present invention, it is possible to send TCP packets and UDP packets simultaneously at the RLP layer, but nonetheless each packet in the appropriate transmission reliability mode at said RLP layer, which means that the TCP packets can be sent with the desired or necessary reliability in the numbered mode, whereas the UDP packets are not unnecessarily delayed by potential retransmissions by also being sent in the numbered mode.
In connection with the above example, the invention offers great advantages. PPP is used to transport multiple protocols, such as IP, LCP (link control protocol), PAP (password authentication protocol) etc. simultaneously over a serial link. A PPP protocol identifier identifies which protocol data unit (PDU) or protocol packet is contained in a particular PPP packet. IP, which in turn is carried by PPP, can carry packets of multiple protocols, namely TCP, UDP and ICMP (Internet Control Message Protocol), which are also distinguished by a protocol identifier in the IP header. The different protocols that are eventually transported by PPP have different requirements requiring the trade-off between reliability versus delay. Consequently, either the numbered or the unnumbered mode of RLP is appropriate for certain data streams. More specifically, signaling messages such as LCP or PAP should be carried in the numbered mode, whereas real-time data streams (e.g. voice information for an Internet-telephone conversation sent in UDP packets) can usually tolerate losses but are more delay sensitive, which is best served with the unnumbered mode.
In the known implementations and systems this conflict could not be solved. If RLP fixedly running in the numbered mode is used, then a real-time UDP data stream can not run in parallel on a mobile computing device with a data stream (e.g. TCP) that requires the numbered mode. If RLP is not used, then after the circuit-switched connection is established, which means that charges are incurred, the establishment of the PPP link can fail, because LCP packets may get corrupted in the unnumbered mode. Consequently, the subscriber would have to pay for the call but not receive the desired service.
The present invention solves this conflict, because according to the invention the RLP implementation will automatically send the LCP messages in the numbered mode, whereby safe PPP link establishment is ensured, and then send following PPP packets containing UDP packets in the unnumbered mode, so that these are not unnecessarily delayed. Moreover, not only can such a conflict between different kinds of packets sent at different times during one connection be solved, but the present invention also allows two conflicting streams (in terms of reliability) to be sent in parallel, e.g. the above mentioned UDP data stream together with the TCP packets.
It should be noted that the above mentioned protocols and the above mentioned situation are only examples that are used to better explain the embodiment and its advantages. As already mentioned, the embodiment relating to the setting of reliability modes can be applied to any implementation of a protocol that allows for two or more reliability modes. For example, it can also be applied if LLC (Logical Link Control) packets are to be sent over a RLC (Radio Link Control) link. Equally well, the place of implementation is naturally not restricted to the above example of FIG. 6, but will be wherever it is suitable or desirable for the given protocol. For example, in a General Packet Radio Service (GPRS), it would be the TAF and the GSN (GPRS Support Node).
In effect, this means that the application of the present invention to the setting of reliability modes automatically provides virtual transmission reliability channels for the respective number of transmission reliability modes that are provided or chosen, where the implementation places specific types of packets in a specific virtual channel. In the context of the above example, this means that two virtual channels are provided, because there are two transmission reliability modes, i.e. a numbered channel and an unnumbered channel are provided, and TCP packets (more specifically: packets embedding TCP packets) are placed in the numbered channel, and UDP packets are placed in the unnumbered channel.
Expressing the above example in more general terms, the invention may be applied to the transmission scheme of ARQ-based error correction (ARQ=Automatic Repeat request), where the choice of an operating mode (i.e. a reliability mode in this context of ARQ) may be based on the contents of packets being embedded. The possible modes are naturally not restricted to only two, i.e. unreliable (UI-mode) and reliable (I-mode), but may also have a larger number, such as there being a semi-reliable mode in addition to the UI-mode and I-mode, said semi-reliable mode being a combination of the two others with in-sequence-delivery or out-of-sequence delivery.
As can be seen above, the present invention may be applied to the setting of reliability modes, but is by no means restricted thereto. Quite to the contrary, the present invention is applicable to the setting or adjusting of any kind of operating mode in the context of embedding higher layer packets at a lower layer. More specifically, the present invention is applicable to all transmission schemes which have at least two different operating modes, such as the transmission scheme of FCS-based error detection (FCS=Frame Check Sequence) with the operating modes of e.g. the receiver discarding erroneous frames, the receiver marking but not discarding erroneous frames, and the receiver neither marking nor discarding erroneous frames, where the discriminating operation may naturally be made in view of any two of the modes or all three. Or the invention is applicable to the transmission scheme of FEC-based error correction (FEC=Forward Error Control) with the operating modes of e.g. using one of two or more FEC schemes. Or the invention is applicable to the transmission scheme of interleaving-based error prevention with the operating modes of e.g. using one of two or more interleaving schemes. Or the invention is applicable to the transmission scheme of power control with the operating modes of e.g. using one of two or more power levels. Or the invention is applicable to the transmission scheme spreading-based error prevention (in spread-spectrum technologies such as CDMA) with the operating modes of e.g. using one of two or more spreading factors. Or the invention is applicable to the transmission scheme of frame length control with the operating modes of using e.g. one of two or more possible frame lengths. Or the invention is applicable to the transmission scheme of bandwidth reservation control with the appropriate operating modes such as the allocation of 1, 2, 3, . . . or 8 time slots e.g. in the GPRS communication standard.
An important advantage of the present invention lies in the fact that it in principal does not require the alteration of any protocols, but only of its peer implementations, so that it can be applied universally in any appropriate context without compatibility or transition problems.
According to another preferred embodiment, the present invention is applied to provide a way of transmitting packets at a lower layer in accordance with transmission quality requests (such as QoS (Quality of Service) requirements and/or transmission priorities) specified by peers of a higher layer, where the packets or data units of said higher layer are embedded at said lower layer. The peers of the higher layer use the packets of said layer as a vehicle for conveying said quality requests to the lower layer, i.e. there is a standardized scheme by which said quality requests can be understood by implementations of both layers. As an example, this can be done by using a predefined field in the header of the higher layer packets and standardizing the contents of said field. In other words, a type of control channel is provided for conveying quality requests from the higher layer to the lower layer. Said quality requests are not only used to map higher layer packets or flows (a flow is a uniquely identifiable stream of packets) to operating modes provided for the transmission at the lower layer, but also to dynamically adapt the operation modes themselves, at least in part on the basis of said quality requests.
It may be noted that the transmission quality requests are a type of control information that may be used as a quality command for letting the higher layer set a specific operating mode at the lower layer, or may be used by the lower layer implementation liberally such that the lower layer implementation chooses the operating mode for a given packet carrying said quality request on the basis of said quality request, but the higher layer has no direct influence on which mode the lower layer will choose.
Further aspects and advantages of the present invention will become more readily understandable from the following detailed description of preferred embodiments, in which reference is made to the figures which illustrate these preferred embodiments.
BRIEF DESCRIPTION OF FIGURES
FIG. 1 is a block diagram showing an embodiment of a communication device according to the present invention;
FIG. 2 is a flow chart showing an embodiment of a method according to the present invention;
FIG. 3 is a schematic diagram for explaining the concept of protocol layering in terms of the example of the TCP/IP suite;
FIG. 4 is a schematic diagram for explaining the flow of packets through the layers shown in FIG. 3;
FIG. 5 is a schematic diagram showing the concept of encapsulation in the subsequent protocol layers of FIG. 3 and FIG. 4;
FIG. 6 shows a schematic example of a connection between two IP-hosts over a circuit-switched GSM link, and the corresponding hierarchy of layers and protocols;
FIG. 7 shows the basic structure of a HDLC frame;
FIG. 8 is a block diagram of a preferred embodiment of the device according to the present invention;
FIGS. 9a and 9 b are a flow chart showing a preferred embodiment of the method of the present invention;
FIG. 10 shows a communication arrangement for explaining another preferred embodiment of the invention.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
The present invention will be described by way of embodiments relating to the setting of transmission reliability modes. As already mentioned, this is a preferred application of the invention and serves well to illustrate the invention. However, the invention is generally applicable to the setting of any kind of adjustable parameter, e.g. also to the setting of security modes.
A basic embodiment of the present invention will be described by referring to FIG. 1. In accordance with this embodiment, a communication device that is constituted by the implementation of a communication protocol of layer n receives packets from a higher layer (n+1), such that these packets may be embedded into packets of the layer n. As already mentioned, the term “embedding” comprises both encapsulation and segmentation. It should be remarked that the entire introductory portion of the present application is incorporated into the disclosure of the invention, to thereby avoid unnecessary repetitions.
As an example, the protocol of layer n could be RLP and the packets of layer (n+1) could be PPP frames, in which case the embedding would consist in the segmentation of one PPP frame or packet into a plurality of RLP packets. It may be remarked that a PPP frame will typically have a length of 1500 byte, whereas a RLP frame will typically have a length of 30 byte. Another example would be that the protocol of layer n is PPP and the protocol of layer (n+1) is an appropriate higher layer protocol, such as one of the protocols shown in FIG. 5, in which case the embedding would be done by encapsulation.
In accordance with the invention, this embodiment has a discriminator 1 that receives the packet of layer (n+1), where said discriminator discriminates the received packet according to predetermined rules of classification. This means that the discriminator will check for certain properties of the received packet, and then classify the received packet according to the given rules. An example of this could be, in the case that the packets of layer n are PPP frames, to check the individual headers of the received PPP frame to thereby determine what type of information is being transported by said frame, and then accordingly classifying the frame. For example, if the frame is carrying LCP information, then it may be classified into the category “reliable transport”, and if it is carrying UDP information, then it may be classified into the category “reliability not required”.
It is clear that the above mentioned protocols and categories are only examples, and the present invention relates to all types of discriminators that are capable of classifying a received packet in accordance with its contents. As a consequence, these packets can basically be of any protocol and naturally there can be an arbitrary number of categories into which packets are classified. This number of categories can be equal to the number of transmission reliability modes that the protocol of layer n provides, but may also be lower if the protocol of layer n provides for more than two modes of transmission reliability.
The result of the discrimination, i.e. the classification is conveyed to a control means 2 that in turn controls an embedding means 3 with a transmission reliability setting command. In other words, the discriminator passes the packet to be embedded on to the embedding means 3, where it is embedded into one or more packets of layer n and the transmission reliability mode, which is appropriately set in each packet of layer n, e.g. by a corresponding flag, is set in accordance with the transmission reliability setting command.
The thus generated packets of layer n are then appropriately passed on to the next stage of processing. This next stage of processing depends on the specific application, and can therefore be chosen in any desirable or required way. For example, if the packets of layer n are intended to directly go to a next lower layer of (n−1) (not shown in FIG. 1), then it is possible that the packets of layer n will simply be passed to an input buffer of the next layer. On the other hand, if e.g. the packets are intended to be sent over an established link, then they will be preferably placed in an output buffer, which is appropriately controlled in accordance with the given situation. The precise method of flow control from such an output buffer depends on the specific application, e.g. the given protocol of layer n and on the specific link.
As can be seen from the above, the present invention is highly flexible in that it can be applied to any protocol implementation that embeds packets of one layer in packets of another and which provides for at least two different reliability modes.
FIG. 2 shows a flow chart that embodies the method of the present invention. In a first step S1 it is determined if a higher layer protocol packet has been received or not. If such a packet has been received, then the process proceeds to step S2, in which the received packet is discriminated according to predetermined rules of classification. Then in step S3 the received packet is embedded into one or more packets of the given layer (e.g. n in FIG. 1) and the transmission reliability mode in each of said packets is set in accordance with the discrimination result. Finally, the embedded packets are passed on to the next stage, where the process shown in FIG. 2 sends said packets to an output buffer in step S4 for being sent out.
A system corresponding to what is shown in FIG. 1 and having an input and an output buffer is shown in FIG. 8. As can be seen, the device of FIG. 8 also has a discriminator 1, a control means 2 and an embedding means 3, and additionally an input buffer 4 and an output buffer 5 are shown, which are also both connected to and controlled by the control means 2. The operation is similar to that explained in connection with FIG. 1, only that the packets of layer n are provided to the discriminator 1 via the input buffer 4, where the control means 2 performs an appropriate control for letting the input buffer 4 pass packets to the discriminator 1, and in that FIG. 8 shows an example, in which the embedding means 3 passes the packets of layer n to an output buffer, which sends said packets of layer n out under control of the control means 2.
As already mentioned, the present invention is flexible in that any appropriate method of flow control can be chosen. As an example, in case there are two transmission reliability modes, such as the above described numbered and unnumbered mode, then respective packets of layer n can be placed into separate queues in the output buffer 5. In other words, if there are two transmission reliability modes that can be set in the packets of layer n, then the output buffer 5 will contain two queues. If these reliability modes are the numbered and unnumbered mode, then the output buffer will have a queue for packets of the numbered mode and a queue for packets of the unnumbered mode.
In general, one embodiment of this system shown in FIG. 8 can consist in the output buffer 5 carrying a respective queue for each transmission reliability mode into which packets are discriminated by the discriminator 1. Then the packets in the individual queues can be handled in any appropriate or desired way, e.g. there can be a predetermined priority order for the individual queues (i.e. the individual reliability modes). An example of this, in an implementation having only a numbered and an unnumbered mode, could be that there is no basic priority order between numbered and unnumbered packets for first packets to be sent (these packets are treated in a FIFO manner regardless of which queue they belong to), but that numbered packets that are to be retransmitted receive a higher priority and are consequently preferably transferred. Also in such a case, the flow control of packets from the numbered mode queue can be conducted in accordance with the known window-based flow control, whereas the flow control from the unnumbered mode queue can be done by simply sending these packets out in the appropriate order.
However, other possibilities exist equally well, as will be explained in more detail in connection with other preferred embodiments further on.
A preferred embodiment for the method of the present invention is shown in FIGS. 9a and 9 b. Steps corresponding to those already discussed in connection with FIG. 2 carry the same reference numerals. The method shown in FIGS. 9a and 9 b relates to a case in which the invention is applied to the implementation of a protocol, where said protocol provides a numbered reliability mode (I-mode) and an unnumbered reliability mode (UI-mode). In other words, in the numbered mode, packets are retransmitted if they are not correctly received by the receiving peer, where the correct receipt is conveyed to the sending peer by means of acknowledgment packages, and the unnumbered mode does not provide for retransmission.
In FIG. 9, steps equal or equivalent to those described in conjunction with FIG. 2 carry the same reference sign. In a first step S1 it is determined if a higher layer packet has been received. If yes, then the process proceeds to step S21, in which the protocol ID in the header of the received higher layer packet is analyzed. For example, if the higher layer packet received is a PPP frame as shown at the bottom of FIG. 5, then the process will simply check the PPP header directly following the start flag. Then, in step S22 it is determined if the identified protocol ID is associated with the numbered mode, said association being given by the above mentioned predetermined rules. For example, in the case of PPP packets, it is preferable if said rules state that LCP packets be put into the numbered mode, because such LCP packets are part of the link set-up procedure where a high amount of reliability is necessary. Consequently, if in step S22 the process determines that LCP information is being transported, then the procedure branches to step S31, in which the received higher layer packet is embedded into one or more packets of the layer at which the present invention is implemented, where the reliability mode in each of said one or more packets is set to the numbered mode, e.g. by setting the corresponding reliability mode flag in each packet.
If in step S22 it is determined that the identified protocol ID is not associated with the numbered mode, then step S23 determines if the identified protocol ID is associated with the unnumbered mode. If this is the case, then the process proceeds to step S32, in which the received higher layer packet is embedded into one or more packets of the layer at which the present invention is implemented, and the reliability mode in each of said one or more packets is set to the unnumbered mode, e.g. by setting the appropriate flag. If both steps S22 and S23 lead to a negative result, then step S24 specifies that the check proceed up one protocol layer in the received packet, such that the next header be checked. When again looking at the example at the bottom of FIG. 5, this would be the IP header carrying a protocol ID distinguishing TCP, UDP and ICMP data. The process then repeats the steps S21 to S24. If the determined protocol ID can again not be allocated to either the numbered mode or the unnumbered mode, then the process again goes up one protocol layer, e.g. in the example of FIG. 5 to the TCP header.
In general, the association between given protocol packets and the numbered mode or unnumbered mode will be stored in a table that is looked up during the decision steps S22 and S23. Ideally it should be such that all possible protocols are stored in said table, so that any received packet can eventually be classified into the numbered mode or unnumbered mode. However, for reasons of economy, it is equally well possible to implement a fail-safe mechanism into the process shown in FIGS. 9a and 9 b, e.g. a counter in step S24 that only allows a moving up to a next protocol layer for a predetermined number of times, where the exceeding of said predetermined number of times leads to a default mode being assigned to the received packet in question. This default mode can be either the numbered mode or the unnumbered mode. Naturally, other fail-safe mechanisms are possible, and can be chosen in any desired or required way.
Returning to FIG. 9b, after step S31 or S32, the process proceeds to step S4, in which the packets are passed to the output buffer, just as in the case of FIG. 2. The process then turns to step S1 to wait for the next higher layer packet to be received.
In a general way, the method of FIG. 9 embodies a system in which the data packets have one or more sections carrying information on the contents of the packet (e.g. a packet encapsulating a hierarchy of protocols), and the discriminator means is arranged to analyze said one or more sections to thereby discriminate the data packets in accordance with their contents. More specifically, said one or more sections are packet headers associated with respective protocol layers and containing protocol identification information identifying the protocol with which the contents of the packet are associated. The packet headers form a hierarchy in accordance with the protocol layers, and, for a packet to be discriminated, the discriminator is arranged to first determine the protocol identification in the header associated with the first higher layer protocol and then compare said protocol identification with stored rules that allocate a predetermined transmission reliability mode to predetermined protocol identifications. Furthermore, the discriminator is arranged to set the transmission reliability mode for said packet to be discriminated in accordance with a determined allocation if said protocol identification is among the stored rules, and if said protocol identification is not among the stored rules, then determine the protocol identification in the header associated with the next protocol one layer up in the hierarchy and then compare said protocol identification of said next protocol with said stored rules that allocate a predetermined transmission reliability mode,
where the process of determining and comparing is repeated until either a determined protocol identification in said packet to be discriminated is allocated to a predetermined transmission reliability mode according to one of the rules, in which case said transmission reliability mode is set for said packet to be discriminated, or a fail-safe condition is met, in which case a default transmission reliability mode is set for said packet to be discriminated.
Preferably, the present invention is applied to the implementation of protocols that use segmentation for embedding higher layer packets into the packets to be sent over a link, and said protocols support two transmission reliability modes, namely a numbered mode and an unnumbered mode. Examples of such protocols are protocols for handling communication over radio links, such as the above mentioned RLP and RLC.
The application of the present invention to such protocols is preferably done in accordance with the embodiments shown in FIGS. 8 and 9.
Preferably in such a case, the invention then not only has specific features for embedding packets to be sent, but also comprises specific features relating to the receipt of such embedded link layer protocols from a sending peer, i.e. features that relate to the implementations properties as a receiving peer.
In the following, a number of basic mechanisms for a peer of a link layer protocol acting as both a sender and a receiver will be explained with the help of an example using RLP as a link layer protocol embedding PPP frames by means of segmentation. It should however be remarked that these protocols are only examples for the purpose of explanation, such that the described mechanisms may be put to practice with any other appropriate protocol.
According to a basic mechanism, the RLP sender analyses the data stream being passed to it from a higher layer, e.g. the PPP frames, to determine in which mode each higher layer frame is to be sent, i.e. in the numbered mode or unnumbered mode. This process will be done as described in connection with FIGS. 8 and 9, such that a repetition is not necessary here. The flow control of packets from the output buffer is performed such that RLP packets in the numbered mode and unnumbered mode are sent out on a FIFO basis with respect to the first sending (of numbered mode packets, because unnumbered mode packets are always only sent once), but RLP packets of the numbered mode that are to be retransmitted have a higher priority and are therefore always sent as soon as possible.
The RLP receiver separates the packets of the unnumbered mode and numbered mode into respective and distinct buffers or at least distinct queues. Like the RLP sender, the RLP receiver always analyses the data in each buffer to thereby discriminate higher layer frames. Only once a complete higher layer frame has been received, will it be released to the higher layer on the receiving side. A problem may occur for packets sent in the unnumbered mode, because in such packets the delimiter (e.g. start or end flag) for the higher layer packet may get corrupted during the transmission, as no retransmission takes place. For this case the RLP receiver is adapted to employ a fixed buffer limit for packets of the unnumbered mode, beyond which packets of the unnumbered mode will be released to the next higher layer regardless if a delimiter has been received or not. More specifically, after the fixed buffer limit is exceeded, the RLP receiver will release every RLP packet of the unnumbered mode to the next higher layer until another higher layer packet delimiter has been detected. Using said higher layer packet delimiter as a new starting point, the RLP receiver can then again wait for the next higher layer packet delimiter, i.e. until the next complete higher layer packet has been received.
Another mechanism for enabling the RLP receiver to distinguish the individual higher layer packets is to have the RLP sender duplicate every higher layer delimiter it detects in the data that it sends out. In other words, in addition to discriminating the data in accordance with its contents, the RLP sender will also look for the delimiters of the next higher layer, e.g. PPP, and always insert an identical delimiter next to each delimiter it detects. It is advantageous if the above mentioned process in response to a fixed buffer limit being exceeded is retained in the receiving features of the RLP implementation, i.e. if the feature of delimiter duplication by the implementation of the sender is combined with buffer limit feature relating to the implementation of the sender.
Another mechanism relating to both the sending and receiving features of an RLP implementation will now be discussed. The sender features are again as described above, namely the sender analyses the data stream it receives to determine in which mode each higher layer frame is to be sent, i.e. in the numbered mode or unnumbered mode. Flow control from the output buffer is conducted in such a way that retransmitted numbered mode packets always have a higher priority. Regarding the receiving features of the RLP implementation, the receiver is able to separate the numbered mode and unnumbered mode packets it receives into distinct buffers or queues, just as in the previously explained case. Now, the receiver only analyses numbered mode packets to discriminate higher layer packets (e.g. PPP frames). In general, the receiver immediately releases numbered mode and unnumbered mode packets to the higher layer, with the usual restriction that numbered mode data can only be released in the correct order. In other words, this means that the receiving buffer will usually not hold the received packets but much rather immediately release them, except for numbered mode packets for which retransmission is taking place, because then a certain amount of these numbered packets have to be buffered, because they can only be released in the correct order to the higher layer. Another exception is explained in the following.
With this rule concerning how the receiver releases packets to the higher layer on its side, four cases may be distinguished:
(a) only unnumbered mode packets are being transmitted (for example the sender is only sending UDP packets, which may be referred to as a UDP session), where no problem occurs in this case;
(b) only numbered mode packets are being transmitted (for example the sender is only sending TCP packets, which can also be referred to as a TCP session), where again no problem occurs;
(c) unnumbered mode packets followed by numbered mode packets are being transmitted (for example a UDP session followed by a TCP session), where again no problem occurs; and
(d) numbered mode packets followed by unnumbered mode packets are being transmitted (for example a TCP session followed by a UDP session, or a UDP and TCP session that run in parallel), where a problem can occur, if numbered mode packets have to be retransmitted and unnumbered mode packets are being received in the meantime.
To solve this problem of case (d), the following mechanism may be used. As long as the higher layer packet which was sent in the numbered mode has not been completely received (e.g. because the packet which contains the PPP frame delimiter marking the end of a TCP packet has to be retransmitted) the unnumbered mode packets have to be buffered. The buffer will not be released to the higher layer before the whole numbered mode packet has been received and released. After the numbered mode packet has been completely received and released to the next higher layer, the contents of the buffer containing unnumbered mode packets is released. Then normal operation continues.
According to a preferred embodiment of the above mentioned mechanism, the receiver additionally has knowledge or information on which packet delimiter is being used. The default delimiter should be the delimiter of the usual packets of the next higher layer (e.g. the PPP frame delimiter), but if another delimiter shall be used, this can be negotiated between the two link layer entities, i.e. the two RLP peers. This in other words means that other protocol packets of the next higher layer could be processed, i.e. those of more than one protocol. In the context of the above example relating to PPP frames being embedded in RLP packets, this means that the RLP implementation could then not only embed PPP frames but frames of other protocols as well, where said other protocols belong to the same layer as PPP. There are a variety of possibilities of how the receiver can obtain this information. In the case of link layer protocols based on HDLC (such as GSM RLP) using a special signaling frame or XID frame, which is a standard HDLC frame for link parameter negotiation, said XID frame having a new parameter can be used.
Another mechanism, which only relates to the sending features, will now be described. In other words, the receiver implementation will not be changed in any way. Thus, the receiver will always release unnumbered mode packets when received and the delivery of numbered mode packets is as usual released in order. Therefore it is up to the sender to make sure that the higher layer packets (e.g. PPP frames) will be released correctly at the receiver. This can be done in such a way that before the sender starts an unnumbered mode session, no unacknowledged numbered mode packet is allowed to be outstanding, i.e. all numbered mode packets have to be acknowledged by the receiver. Although this mechanism is simpler to implement, as it does not change the receiving features, it results in an extra delay introduced when switching between a numbered mode session and an unnumbered mode session.
Finally, another mechanism could consist in controlling the output buffer of the sender in such a way that when an unnumbered mode session is being run by the sender, all unnumbered mode packets to be sent should be sent in consecutive RLP frames carrying the unnumbered flag.
As already mentioned previously, the above described mechanisms have been explained by using RLP and PPP as preferred examples, but these mechanisms are naturally not restricted to these protocols. Much rather they can be implemented for any protocols having the suitable features.
In the above embodiments, the invention was described with regard to discriminating with respect to a specific field in the packet header of a packet being embedded, namely the protocol ID field of higher layers, and with respect to the specific transmission scheme of ARQ-based error recovery, using the two operating modes relating to reliability, namely the numbered mode and the unnumbered mode. The invention is by no means restricted thereto.
Much rather, the invention may equally well be applied to discriminating with respect to any packet content in any part of a packet, such as also the above mentioned DS field or IP option. Regarding the operating modes associated with ARQ, naturally more than two may be employed, such as e.g. the alraedy mentioned numbered and unnumbered mode supplemented by a mixed mode.
The present invention is also not restricted with respect to the transmission scheme of ARQ, i.e. error recovery, but may also be applied to any operating modes associated with any type of forward error correction. More specifically, the present invention is applicable to all transmission schemes which have at least two different operating modes, such as the transmission scheme of FCS-based error detection (FCS=Frame Check Sequence) with the operating modes of e.g. the receiver discarding erroneous frames, the receiver marking but not discarding erroneous frames, and the receiver neither marking nor discarding erroneous frames, where the discriminating operation may naturally be made in view of any two of the modes or all three. Or the invention is applicable to the transmission scheme of FEC-based error correction (FEC=Forward Error Control) with the operating modes of e.g. using one of two or more FEC schemes. Or the invention is applicable to the transmission scheme of interleaving-based error prevention with the operating modes of e.g. using one of two or more interleaving schemes. Or the invention is applicable to the transmission scheme of power control with the operating modes of e.g. using one of two or more power levels. Or the invention is applicable to the transmission scheme spreading-based error prevention (in spread-spectrum technologies such as CDMA) with the operating modes of e.g. using one of two or more spreading factors. Or the invention is applicable to the transmission scheme of frame length control with the operating modes of using e.g. one of two or more possible frame lengths. Or the invention is applicable to the transmission scheme of bandwidth reservation control with the appropriate operating modes such as the allocation of 1, 2, 3, . . . or 8 time slots e.g. in the GPRS communication standard.
Naturally, all of these transmission schemes and operating modes may be combined in any arbitrary and suitable way. This means that the discriminating may be conducted in view of generalized operating modes that consist e.g. of a combination of ARQ-related mode and power control related mode, such for example the numbered mode, the unnumbered mode, and 4 power levels are combined to achieve 8 modes, i.e. (I-mode, power level 1), (I-mode, power level 2), . . . , (UI-mode, power level 4). As already mentioned, arbitrary combinations are possible, as is best suited for the specific application.
Now a further preferred embodiment of the invention will be described in connection with FIG. 10. According to this preferred embodiment, the present invention is applied to provide a way of transmitting packets at a lower layer in accordance with transmission quality requests such as QoS (Quality of Service) requirements and/or transmission priorities specified by peers of a higher layer, where the packets or data units of said higher layer are embedded at said lower layer.
In the following description the term L3 will be used to refer to a network layer protocol, e.g. IPv4 or IPv6, also see FIG. 3. The L3 protocol data unit (PDU) will be referred to as a packet, and the PDU header as a packet header. The term L1/L2 will be used to refer to a protocol or a set of two or more protocols below L3, such as the physical and/or the link layer of a specific network, again see FIG. 3. The term bearer will be used for an L1/L2 with either fixed settings for all L1/L2 operating modes or fixed QoS (Quality of Service) settings to which all L1/L2 operating modes are dynamically adapted depending on the momentary conditions of the medium underlying, L1/L2 (e.g. radio). The term peers will be used as above, i.e. as relating to processes that communicate according to a common protocol of a certain layer. Examples are a WWW client and server communicating according to the HTTP protocol on the application layer, or a TCP sender and receiver on the transport layer, also see FIG. 6. In the following context, the term peer will always refer to peers which communicate according to protocols which are directly or indirectly based on L3. The term flow will refer to a single instance of peer-to-peer L3-packet-based (packet-switched) traffic which is identified by source address, source port, destination address, destination port and protocol ID. In other words, a flow is a uniquely identifiable stream of packets. Each flow is considered as having certain QoS requirements. QoS requirements may vary over time.
It may be noted that when it is said that a peer (e.g. a legacy WWW browser) chooses the QoS requirements for its flow, this also comprises that some other process does this on behalf of the peer.
FIG. 10 shows a communication between a mobile IP-host suitably linked (in FIG. 10 over a so called bluetooth link) to a mobile telephone adapted to transport IP packets. The telephone in turn can establish a radio link with a wireless access network, where any suitable communication standard can be used, such as e.g. GSM, GPRS or W-CDMA. The wireless access network is connected to the Internet, which comprises a multitude of hosts, two of which are shown in FIG. 10.
The lower part of the figure schematically shows the communication situation. Peers A.1 and B.1 are shown as examples on the mobile side, and peers A.2 and B.2 as their respective counterparts. These peers may pass QoS requirements and/or transmission priorities, i.e. in general quality requests as control information, to the L3 layer. The peers are either L3 peers or of protocol layers above L3. This can be done by specifying a given field in the L3 header as relating to quality requests, such that the L3 layer is used as a level through which peers express their QoS requirements and/or priorities on a per flow or per packet basis.
The discrimination of L3 packets is handled by a controller or controlling process 11 at each side of L1/L2, which in turn controls an adapter or adaptation process 12 in response to the discrimination result. The controlling process 11 “reads” the per packet QoS requirements and/or priorities and maps them to respective L1/L2 operating modes and/or priorities of that network. The adaptation process 12 is capable of adapting the L1/L2 operating modes on a per packet basis and makes this decision at least in part dependent on the information provided by the controller. Typically, the adaptation of the L1/L2 operating modes will also be conducted on the basis of measured conditions of the medium underlying L1/L2.
As a consequence, the present embodiment comprises dynamically adapting L1/L2, where L1/L2 is adaptable on a per packet basis, and having a control process which has access to the per flow/packet QoS requirements and/or priorities and which can use those to control the adaptation process and/or the L1/L2 scheduler(s) accordingly.
As an example, the optimal adaptation of L1/L2 for TCP would use ARQ-based error recovery in I-mode and other transmission schemes, e.g. FEC to be optimized for highest throughput. On reading the protocol ID field (which says that it is a TCP flow) in the packet header, the controller can make the appropriate decision, e.g. for a mobile-terminated TCP flow. The optimal adaptation for a real-time VoiceOverIP flow (e.g. broadcast radio which does not have a session initiation protocol) would use no ARQ-based error recovery (UI-mode) and other transmission schemes, e.g. FEC to be optimized to the source transmission rate and lowest residual error. On reading the DS field in the packet header, the controller can make the appropriate decision, e.g. for a mobile-terminated real-time VoiceOverIP flow.
The above described embodiment solves a problem of known L1/L2 protocol implementations. L1/L2 of state-of-the-art networks (e.g. wireless networks) have to simultaneously transport different flows each potentially having different QoS requirements. However, L1/L2 of state-of-the-art networks cannot be adapted down to the level of exactly meeting the QoS requirements of individual flows, and also not one step further down to the level of meeting the QoS requirements of individual packets of a flow. The latter could e.g. be required for flows which have QoS requirements that vary over time so that different packets of the same flow have different QoS requirements. Instead, state-of-the-art networks can at most only support one or more bearers simultaneously. However, the way that flows are mapped onto those bearers is not directly related to the QoS requirements of those flows but is based on criteria like priorities, which e.g. correspond to network operator charges per packet (as e.g. done in the GPRS communication system). The resulting problem is that either the QoS requirements of some Flows/packets are not met, or the QoS requirements of some flows/packets are met but only in a non-optimal way (e.g. the FEC scheme chosen for a TCP window flow is too strong providing a lower bit rate than could have been provided with the optimal FEC scheme), or the QoS requirements of some flows/packets are exceeded, which corresponds to wasted network resources (e.g. spectrum or transmission power).
It should be noted that the adaptation of L1/L2 to the QoS requirements of flows is independent of the concept of priority-based traffic scheduling. For example, a real-time voice stream will have specific QoS requirements independent of whether it is assigned to the best-effort or some kind of predictive QoS traffic class.
The present embodiment solves this problem by dynamically adapting L1/L2 to the QoS requirements of each flow or packet. It provides the following functionalities and their interworking:
functionality 1: a standardized scheme through which the QoS requirements for individual flows/packets can be uniquely specified so that the semantics are the same in any network supporting that scheme;
functionality 2: an adaptation process which can adapt L1/L2 according to operating modes provided by a control process. The operation modes can either be provided explicitly or implicitly in a form that only has local semantics, e.g. with respect to QoS which are specific for the network of that L1/L2. The adaptation process can combine the operating modes provided by the control process with measurement information about conditions of the medium (e.g. radio) underlying L1/L2 to eventually decide on the final operating mode. This is however only an implementation detail;
functionality 3: a control process which is capable of controlling the adaptation process on a per flow/packet basis given the QoS requirements of each flow/packet by having access to the control channel; and
functionality 4: a control channel through which the per flow/packet QoS requirements can be made available to the control process.
It may be noted that the adaptation and the control process each can either be distributed processes, e.g. one process per L1/L2 transmission scheme, or a single process adapting/controlling all L1/L2 transmission schemes. This is again an implementation detail. It may also be noted that the above described functionalities require an L1/L2 which can be adapted on a per packet basis or at least on a per packet sequence basis, e.g. it must be possible to change the FEC from one packet to the other or at least from one sequence of packets to the other.
Regarding what is known from the state of the art of RfC 2475, it must specifically be remarked that RfC 2475 does not hint at dynamically adapting L1/L2. Moreover, it is not known from the prior art to implement L1/L2 to be adaptive with respect to QoS requirements of individual packets/flows (functionality 2), and it is not known to provide the control process of functionality 3.
Using the communication systems of GSM-CSD or GPRS as examples of state-of-the-art networks, a number of scenarios may be given for showing that both networks are missing functionalities to support per flow/packet adaptation.
Taking the arrangement of peers A.1, B.1, A.2 and B.2 from FIG. 10 as a n example (i.e. without the features of the invention), then, in a conventional network, peers that are physically close (e.g. A.1 and B.1) to L1/L2 in GSM-CSD and GPRS have a direct control channel to adapt that L1/L2 according to QoS which are explicitly known to that peer (or a process that acts on its behalf). For example peers A.1 and B.1 could have access on an AT command interpreter through which it can be chosen to run a reliable link layer protocol (RLP) or not to do so (transparent or non-transparent mode). Using RLP would e.g. be optimal for a TCP flow. On the other hand peers A.2 and B.2 would have no way of adapting different L1/L2s for a TCP-flow they initiate. There is also no control process (functionality 3) which could perform the adaptation on behalf of peer A.2 and/or B.2.
GSM-CSD is only capable of operating according to fixed modes (e.g. FEC scheme x and I-mode error recovery) for the duration of the circuit switched call, although several flows with potentially different QoS requirements may have to be transported simultaneously.
It should be remarked that although the invention has been described with reference to specific embodiments, this should not be seen as restricting the invention to these embodiments, as these have been presented for the sake of clarity and completeness, but the invention is to be seen as defined by the appended claims. Reference signs in the claims serve to make the claims more readily understandable and do not limit the scope.

Claims (43)

What is claimed is:
1. A communication device comprising:
a discriminator means arranged for receiving and discriminating data packets of a second data structure according to predetermined rules on the basis of contents of said data packets of said second data structure;
an embedding device for generating data packets of a first data structure determined by a first predetermined protocol, said embedding device being arranged to receive said data packets of said second data structure and generate said data packets of said first data structure by embedding each of said data packets of said second data structure in at least one of said data packets of said first data structure; and
wherein said embedding device is adapted to adjust an operation mode for at least one of said data packets of said first data structure on the basis of a discrimination result relative to at least one of said data packets of said second data structure, said embedding device for setting a transmission reliability mode in each said data packet of said first data structure prior to sending each said data packet of said first data structure, wherein said first predetermined protocol supporting at least two transmission reliability modes according to which said data packets of said first protocol are sent, where said transmission reliability modes are distinguishable at least with respect to rules regarding the retransmission of said data packets of said first data structure, and where each said generated data packet of said first data structure contains information on the associated transmission reliability mode according to which said data packet of said first data structure is to be sent, such that a receiver of each said data packet of said first data structure may determine according to which of said transmission reliability modes which of said data packets of said first protocol were sent;
said discriminator means being arranged to discriminate a given data packet of said second data structure according to said predetermined rules, such that the information on the transmission reliability mode in the at least one of said data packets of said first data structure containing said given data packet of said second data structure is set in accordance with the discrimination result;
an output buffer, into which the data packets of said first data structure are passed; and
said output buffer being arranged to place each data packet of said first data structure in a queue associated with the transmission reliability mode set in said each packet; and
wherein a first transmission reliability mode comprises rules for the retransmission of data packets under predetermined conditions and a second mode provides for no retransmission of data packets, and said output buffer is arranged to send out data packets of said first mode that are to be retransmitted with a higher priority than other data packets.
2. The communication device according to claim 1, further including:
said data packets of said second data structure have at least one section carrying information on the contents of the data packets of the second data structure, and said discriminator means is arranged to analyze said at least one section to thereby discriminate said data packets of said second data structure in accordance with their contents;
said at least one section comprising packet headers associated with respective protocol layers and containing protocol identification information identifying the protocol with which the contents of the data packets of the second data structure are associated, said packet headers form a hierarchy in accordance with the protocol layers; and
said discriminator means is arranged to:
determine the protocol identification information of said given data packet of said second data structure in the header associated with said second protocol and then compare said protocol identification information associated with stored rules that allocate a predetermined transmission reliability mode to predetermined protocol identifications information; and
set the transmission reliability mode for said given data packet to be discriminated in accordance with a determined allocation if said protocol identification information in the header is among the stored rules, and if said protocol identification information is not among the stored rules, then determine the protocol identification in the header of said given data packet associated with a next protocol layer one layer up in the hierarchy and then compare said protocol identification information in the header of said next protocol with said stored rules; wherein
said process of determining and comparing is repeated until a given one of said protocol identification information in said given data packet to be discriminated is allocated to said predetermined transmission reliability mode according to one of the stored rules, in which case said transmission reliability mode is set for said given data packet to be discriminated, and a fail-safe condition is met, in which case a default transmission reliability mode is set for said given data packet to be discriminated.
3. The communication device according to claim 1, wherein a first transmission reliability mode comprises rules for the retransmission of data packets under predetermine conditions, and a second mode that provides for no retransmission of data packets.
4. The communication device according to claim 3, wherein said first protocol specifies performing segmentation in order to embed said data packets of said second data structure in said data packets of said first data structure.
5. The communication device according to claim 4, said discriminator means further adapted to determine the occurrence of a packet delimiter belonging to a data packet of said second data structure it data packets of said second data structure that are to be embedded, and to duplicate said packet delimiters prior to embedding.
6. The communication device according to claim 4, further including:
said first protocol is a protocol for sending said data packets over a link the retransmission of said data packets belonging to said first transmission reliability mode is decided on the basis of acknowledgment data packets for said data packets already sent over said link; and
an output buffer means is provided that is adapted to send out said data packets belonging to said second transmission reliability mode only if the receipt of all previously sent said data packets of said first transmission reliability mode has been acknowledged.
7. The communication device according to claim 4, further including a receiving buffer for receiving said data packets of said first data structure over said link, wherein said first protocol is a protocol for sending said data packets over a link, said receiving buffer comprises:
a first part associated with said first transmission reliability mode for storing said data packets sent in accordance with said first transmission reliability mode; and
a second part associated with said second transmission reliability mode for storing said data packets sent in accordance with said second transmission reliability mode.
8. The communication device according to claim 7, further including:
said first transmission reliability mode being such that said data packets of said first transmission reliability mode are numbered to thereby specify a correct order; and
said receiving buffer adapted to determine the occurrence of a packet delimiter belonging to a said packet of said second data structure in received said data packets of said first data structure belonging to said first transmission reliability mode.
9. The communication device according to claim 7, said receiving buffer further adapted to determine the occurrence of a packet delimiter belonging to a said data packet of said second data structure in received said data packets of said first data structure, and adapted to store said received data packets of said first data structure until one of:
a complete said data packet of said second data structure has been received, which is determined by the receipt of said packet delimiters belonging to said data packets of said second data structure; and
for said data packets of said first data structure belonging to said second transmission reliability mode, a predetermined buffer limit is exceeded.
10. The communication device according to claim 9, said determined packet delimiter specified by a message received over said link.
11. The communication device according to claim 1, wherein said embedding device is arranged to segment said data packets of said second data structure in said data packets of said first data structure.
12. The communication device according to claim 1 wherein said embedding device is arranged to encapsulate said data packets of said second data structure in said data packets of said first data structure.
13. The communication device according to claim 1, further comprising an output buffer, into which said data packets of said first data structure are passed, and from which said data packets are sent out.
14. The communication device according to claim 1, wherein said data packets of said second data structure transport at least one section carrying information on the contents of said data packet, and said discriminator means is arranged to analyze said at least one section to thereby discriminate said data packets of said second data structure in accordance with their contents.
15. The communication device according to claim 14, wherein said at least one section comprises packet headers associated with respective protocol layers and containing protocol identification information identifying the protocol with which the contents of said data packet are associated.
16. The communication device according to claim 1, wherein said first predetermined protocol is a protocol for sending said data packets over a link.
17. The communication device according to claim 16, wherein said link is a radio link.
18. The communication device according to claim 16, wherein said communication device is arranged to also receive said data packets of said first data structure over said link.
19. A method for generating data packets having a first data structure determined by a first predetermined protocol, the method comprising steps of:
discriminating received data packets of a second data structure determined by a second predetermined protocol according to predetermined rules on the basis of contents of said data packets of said second data structure;
adjusting an operation mode for at least one of said data packets of said second data structure on the basis of a discrimination result for at least one of said data packets of said second data structure; and
embedding said data packets of said second data structure in said data packets of said first data structure;
setting a transmission reliability mode in a said data packet of said first data structure containing a given said data packet of said second data structure according to the result of said discriminating step for said given data packet of said second data structure, wherein said first predetermined protocol supporting at least two transmission reliability modes according to which said data packets of said first data structure may be sent, said transmission reliability modes are distinguishable at least with respect to rules regarding the retransmission of said data packets of said first data structure, and each generated said data packet contains information on the transmission reliability mode according to which each said data packet is to be sent, such that a receiver of each said data packet may determine according to which of said transmission reliability modes each said data packet was sent;
determining the protocol identification in a packet header associated with said second protocol;
comparing said protocol identification with stored rules that allocate a predetermined transmission reliability mode to predetermined protocol identifications, wherein said data packets of said second data structure have at least one section carrying information on the contents of said data packet, and wherein said at least one section comprises packet headers associated with respective protocol layers and containing said protocol identification information identifying the protocol with which the contents of said data packet of said second data structure are associated, and said packet headers form a hierarchy in accordance with the protocol layers; and
setting the transmission reliability mode for said data packet of said second data structure to be discriminated in accordance with a determined allocation if said protocol identification is among the stored rules, and if said protocol identification is not among the stored rules, then determining the protocol identification in a header associated with the next protocol one layer up in the hierarchy and then comparing said protocol identification of said next protocol with said stored rules that allocate said predetermined transmission reliability mode; wherein
said process of determining and comparing is repeated until one of:
said determined protocol identification in said data packet to be discriminated is allocated to said predetermined transmission reliability mode according to one of rules, in which case said transmission reliability mode is set for said data packet to be discriminated; and
a fail-safe condition is met, in which case a default transmission reliability mode is set for said data packet to be discriminated.
20. The method according to claim 19, wherein said step of embedding further includes encapsulating said data packets of said second data structure in said data packets of said first data structure.
21. The method according to claim 19, wherein said step of embedding further includes
segmenting said data packets of said second data structure in said data packets of said first data structure.
22. The method according to claim 19, wherein said data packets of said first data structure are passed into an output buffer.
23. The method according to claim 19, further including the step of passing said data packets of said first data structure into an output buffer, said output buffer placing each said data packet of said first data structure in a queue associated with the transmission reliability mode set in each said data packet.
24. The method according to claim 23, wherein a first transmission reliability mode comprises rules for the retransmission of said data packets of said first data structure under predetermined conditions, and a second transmission reliability mode provides for no retransmission of said data packets, and said output buffer sends out said data packets of said first transmission reliability mode that are to be retransmitted with a higher priority than other said data packets.
25. The method according to claim 19, wherein a first transmission reliability mode comprises rules for the retransmission of said data packets of said first data structure under predetermined conditions, and a second transmission reliability mode provides for no retransmission of said data packets.
26. The method according to claim 25, wherein said first protocol specifies performing segmentation in order to embed said data packets of said second data structure in said data packets of said first data structure.
27. The method according to claim 26, further including the step of determining the occurrence of a packet delimiter belonging to a said data packet of said second data structure in said data packets of said second data structure that are to be embedded, and duplicating said packet delimiters prior to said step of embedding.
28. The method according to claim 26, wherein said first protocol is a protocol for sending said data packets of said first data structure over a link the retransmission of said data packets belonging to said first transmission reliability mode is decided on the basis of acknowledgment packets for said data packets already sent over said link, and an output buffer is provided that sends out said data packets belonging to said second transmission reliability mode only if the receipt of all previously sent said data packets of said first transmission reliability mode have been acknowledged.
29. The method according to claim 26, further including the step of receiving said data packets of said first data structure over a link into a receiving buffer, said receiving buffer comprises a first part associated with said first transmission reliability mode for storing said data packets sent in accordance with said first transmission reliability mode, and a second part associated with said second transmission reliability mode for storing data packets sent in accordance with said second transmission reliability mode.
30. The method according to claim 29, further including the steps of:
determining the occurrence of a packet delimiter belonging to a said data packet of said second data structure in received said data packets of said first data structure belonging to said first transmission reliability mode, wherein said firs transmission reliability mode being such that said data packets of said first transmission reliability mode are numbered to thereby specify a correct order; and
said receiving buffer immediately releasing said received data packets of said first data structure, both those belonging to said first and said second transmission reliability mode, to the next higher layer, unless one of:
said data packets belonging to said first transmission reliability mode need to be retransmitted, in which case said received data packets belonging to said first transmission reliability mode are buffered until they can be released in the correct order; and
said data packets belonging to said first transmission reliability mode are followed by said data packets belonging to said second transmission reliability mode, in which case said receiving buffer is adapted to immediately release said received data packets of said first data structure belonging to said second transmission reliability mode if no said data packets of said first transmission reliability mode are being stored, and to store said received data packets of said first data structure belonging to said second transmission reliability mode if said data packets of said first transmission reliability mode are being stored, until a complete said data packet of said second data structure and said first transmission reliability mode has been received and released, after which the stored said data packets of said first data structure belonging to said second transmission reliability mode are released.
31. The method according to claim 29, further including the steps of:
determining the occurrence of a packet delimiter belonging to a said data packet of said second data structure in said received data packets of said first data structure; and
said receiving buffer storing said received data packets of said first data structure until one of:
a complete said data packet of said second data structure has been received, which is determined by the receipt of said packet delimiters belonging to said data packets of said second data structure; and
for said data packets of said first data structure belonging to said second transmission reliability mode, a predetermined buffer limit is exceeded.
32. The method according to claim 31, said predetermined packet delimiter being specified by a message received over said link.
33. The method according to claim 19, wherein said data packets of said second data structure transport at least one section carrying information on the contents of said data packet of said second data structure, and said discrimination step comprises analyzing said at least one section to thereby discriminate said data packets of said second data structure in accordance with their contents.
34. The method according to claim 33, wherein said at least one section comprises packet headers associated with respective protocol layers and containing protocol identification information identifying the protocol with which the contents of the said data packet of said second data structure are associated.
35. The method according to claim 19, wherein said first protocol is a protocol for sending said data packets of said first data structure over a link.
36. The method according to claim 35, wherein said link is a radio link.
37. The method according to claim 35, further receiving said data packets of said first data structure over said link.
38. The method according to claim 19, further including the steps of:
mapping said data packets of said second data structure to an operation mode on the basis of a discrimination result;
generating adaptation control data on the basis of said discrimination result; and
selecting one of said at least two operating modes in response to said adaptation control data wherein said first predetermined protocol supports at least two operation modes according to which said data packets of said first data structure are sent.
39. The method according to claim 38, wherein said selecting step takes into account data associated with the link over which said data packets of said first data structure are sent when selecting one of said at least two operating modes in response to said adaption control data.
40. The method according to claim 38, wherein said mapping step includes mapping said data packets of said second data structure on the basis of the contents of a predetermined field in the header of said data packets of said second data structure.
41. The method according to claim 40, wherein said predetermined field carries transmission quality requests as a part of said data packets of said second data structure.
42. The method according to claim 38, wherein said operating modes are associated with at least one of an automatic repeat request error recovery and a forward error correction.
43. The method according to claim 40, wherein said forward error correction comprises at least one of a frame check sequence based error detection, a forward error control based error correction, an interleaving-based error prevention, a power control, a spreading-based error prevention, a frame length control, and a bandwidth reservation control.
US09/353,853 1998-07-15 1999-07-15 Communication device and method Expired - Lifetime US6697352B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/644,473 US7382763B2 (en) 1998-07-15 2003-08-20 Communication device and method

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
EP98113212A EP0973302A1 (en) 1998-07-15 1998-07-15 Device and method for reliable and low-delay packet transmission
EP98113212 1998-07-15
EP99101121 1999-01-21
EP99101121A EP0975123A1 (en) 1998-07-15 1999-01-21 Communication device and method for reliable and low-delay packet transmission

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US10/644,473 Continuation US7382763B2 (en) 1998-07-15 2003-08-20 Communication device and method

Publications (1)

Publication Number Publication Date
US6697352B1 true US6697352B1 (en) 2004-02-24

Family

ID=26149435

Family Applications (2)

Application Number Title Priority Date Filing Date
US09/353,853 Expired - Lifetime US6697352B1 (en) 1998-07-15 1999-07-15 Communication device and method
US10/644,473 Expired - Lifetime US7382763B2 (en) 1998-07-15 2003-08-20 Communication device and method

Family Applications After (1)

Application Number Title Priority Date Filing Date
US10/644,473 Expired - Lifetime US7382763B2 (en) 1998-07-15 2003-08-20 Communication device and method

Country Status (9)

Country Link
US (2) US6697352B1 (en)
EP (2) EP0975123A1 (en)
JP (1) JP4334770B2 (en)
CN (1) CN1188991C (en)
AT (1) ATE312461T1 (en)
AU (1) AU756050B2 (en)
CA (1) CA2337050C (en)
DE (1) DE69928812T2 (en)
WO (1) WO2000004680A1 (en)

Cited By (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010043615A1 (en) * 2000-02-26 2001-11-22 Park Jeong-Hoon Apparatus for transmitting/receiving a bit stream in a network and method therefor
US20020015417A1 (en) * 2000-07-12 2002-02-07 Nec Corporation Communication system between a radio communication network and a connectionless network and interworking apparatus for use in the communication system
US20020026614A1 (en) * 2000-03-29 2002-02-28 Dong-Seek Park Method and apparatus for transmitting and receiving wireless packet
US20020124095A1 (en) * 2001-03-02 2002-09-05 Sultan Israel Daniel Apparatus and method for sending point-to-point protocol over ethernet
US20020142765A1 (en) * 2001-03-30 2002-10-03 Rhoads Monte J. Network appliance wireless configuration interface
US20020141370A1 (en) * 2001-03-12 2002-10-03 Nischal Abrol Method and apparatus for providing multiple quality of service levels in a wireless packet data services connection
US20020143994A1 (en) * 2001-03-30 2002-10-03 Jiming Sun Transmitting new data format under existing infrastructure
US20030070129A1 (en) * 1999-12-08 2003-04-10 Carsten Ball Method for packet-oriented data transmission in a radio communication system
US20030103515A1 (en) * 1999-10-26 2003-06-05 Brown James M. Method and apparatus for efficient data transmission control in a wireless voice-over-data communication system
US20030183691A1 (en) * 2001-02-08 2003-10-02 Markku Lahteenmaki Smart card reader
US20030235206A1 (en) * 2001-02-15 2003-12-25 Tantivy Communications, Inc. Dual proxy approach to TCP performance improvements over a wireless interface
US20040038691A1 (en) * 1999-07-31 2004-02-26 Lg Information & Communications, Ltd. Method for performing cell broadcasting and communication system using the same
US20040078372A1 (en) * 2002-10-18 2004-04-22 Nokia Corporation Method and system for recalling details regarding past events
US20040151206A1 (en) * 2003-01-30 2004-08-05 Scholte Alexander Martin Packet data flow identification for multiplexing
US20040185859A1 (en) * 2001-07-29 2004-09-23 Yuval Barkan Cellular network system and method
US20040190523A1 (en) * 2001-08-22 2004-09-30 Christina Gessner Method and radio sation for transmitting data packets in a radio-communication system
US20040196786A1 (en) * 2003-04-03 2004-10-07 Subhasis Laha Initiation of network treatment for data packet associated with real-time application different from network treatment applicable to data packet non-associated with the real-time application
US6839327B1 (en) * 2000-12-01 2005-01-04 Cisco Technology, Inc. Method and apparatus for maintaining consistent per-hop forwarding behavior in a network using network-wide per-hop behavior definitions
US20050063392A1 (en) * 2003-09-04 2005-03-24 Ntt Docomo, Inc. Packet-priority control apparatus and method thereof
US20050122958A1 (en) * 2003-12-05 2005-06-09 Shim Choon B. System and method for managing a VoIP network
US20050135423A1 (en) * 2003-12-23 2005-06-23 Xiaodong Chen Method and system for RLP optimization
US20050152365A1 (en) * 1999-02-25 2005-07-14 Hitachi, Ltd. Packet communication system with QoS control function
US20050180464A1 (en) * 2002-10-01 2005-08-18 Adondo Corporation Audio communication with a computer
US20050216625A1 (en) * 2004-03-09 2005-09-29 Smith Zachary S Suppressing production of bus transactions by a virtual-bus interface
US20050216638A1 (en) * 2004-03-29 2005-09-29 Smith Zachary S Virtual bus interface production of header-type fields from data-type fields
US20050228926A1 (en) * 2004-04-05 2005-10-13 Smith Zachary S Virtual-bus interface and associated system and method
US6987777B1 (en) * 1999-12-02 2006-01-17 Nortel Networks Ltd Priority forwarding in a communication system
US20060034331A1 (en) * 2004-08-10 2006-02-16 Nokia Corporation Differentiation of quality classes to different PDUs with support for multiple terminals
US20060050638A1 (en) * 1999-01-08 2006-03-09 Michael Meyer Communication device and method
US7031257B1 (en) * 2000-09-22 2006-04-18 Lucent Technologies Inc. Radio link protocol (RLP)/point-to-point protocol (PPP) design that passes corrupted data and error location information among layers in a wireless data transmission protocol
US7039025B1 (en) * 2000-09-29 2006-05-02 Siemens Communications, Inc. System and method for providing general packet radio services in a private wireless network
US20060156198A1 (en) * 2000-09-22 2006-07-13 Lucent Technologies Inc. Complete user datagram protocol (CUDP) for wireless multimedia packet networks using improved packet level forward error correction (FEC) coding
US20070195714A1 (en) * 2000-04-13 2007-08-23 Schales Douglas L Network data packet classification and demultiplexing
US20070220404A1 (en) * 2006-03-20 2007-09-20 Fujitsu Limited IP-data transmitting apparatus and IP-data transmitting method
US20070253270A1 (en) * 2006-04-28 2007-11-01 Hynix Semiconductor Inc. Semiconductor memory device performing self refresh operation
US20080186858A1 (en) * 2007-02-07 2008-08-07 Rehan Jalil Method and apparatus for managing backhaul links in a communication network
US20080205309A1 (en) * 2006-10-04 2008-08-28 Nokia Corporation Virtual adaptation layer for wireless communication
US20090028155A1 (en) * 2003-07-29 2009-01-29 At&T Intellectual Property I, L.P. Broadband access for virtual private networks
US20090067333A1 (en) * 2007-09-07 2009-03-12 Wichorus Inc. Apparatus and method for controlling traffic flow in backhaul link in wireless communication network
US20090219877A1 (en) * 2008-02-29 2009-09-03 Fujitsu Limited Communication apparatus and allocation determining method
US7680100B1 (en) 2004-09-30 2010-03-16 Avaya Inc. Internet protocol appliance manager
US20110044210A1 (en) * 2006-12-27 2011-02-24 Kyocera Corporation Communication System, Wireless Communication Terminal, Communication Method, Wireless Communication Method, Wireless Communication Apparatus and Control Method Thereof
US7933284B2 (en) 2007-03-30 2011-04-26 International Business Machines Corporation Method and apparatus for improving SIP server performance
US20140334442A1 (en) * 2013-05-08 2014-11-13 Qualcomm Incorporated Method and apparatus for handover volte call to umts ps-based voice call
US11128739B2 (en) * 2018-12-24 2021-09-21 Verizon Patent And Licensing Inc. Network-edge-deployed transcoding methods and systems for just-in-time transcoding of media data
US20220346111A1 (en) * 2019-09-29 2022-10-27 Sony Group Corporation Electronic device and method in wireless communication system

Families Citing this family (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6389010B1 (en) * 1995-10-05 2002-05-14 Intermec Ip Corp. Hierarchical data collection network supporting packetized voice communications among wireless terminals and telephones
US7023820B2 (en) * 2000-12-28 2006-04-04 Nokia, Inc. Method and apparatus for communicating data in a GPRS network based on a plurality of traffic classes
US6922548B1 (en) * 2000-04-24 2005-07-26 Microsoft Corporation Providing remote network driver interface specification services over a wireless radio-frequency medium
JP2001245268A (en) * 2000-02-29 2001-09-07 Toshiba Corp Contents transmitting system and content processor
JP2001251366A (en) * 2000-03-07 2001-09-14 Sony Corp Communication system and communication method
JP4479040B2 (en) * 2000-03-07 2010-06-09 ソニー株式会社 Communication apparatus and communication method
DE60042965D1 (en) * 2000-05-24 2009-10-29 Sony Deutschland Gmbh QoS negotiation
KR100667739B1 (en) 2000-06-09 2007-01-12 삼성전자주식회사 Apparatus for transmitting/receiving wireless data and method thereof
CN1809029B (en) * 2001-03-12 2012-01-11 高通股份有限公司 Method and apparatus for providing multiple quality of service levels in a wireless packet data services connection
US7154909B2 (en) * 2001-06-15 2006-12-26 Nokia Corporation Apparatus, and associated method, for facilitating maintenance of sensitivity level of data communicated in a packet communication system
FI113926B (en) * 2001-08-16 2004-06-30 Teliasonera Finland Oyj Monitoring and transmitting the QOS value over a telecommunications network
EP1372310A1 (en) * 2002-06-12 2003-12-17 Motorola, Inc. Apparatus and method for communicating data using header compression
US20040199622A1 (en) * 2003-04-07 2004-10-07 Huscher Anthony Alan eRoom operations console
US7050397B2 (en) 2003-07-02 2006-05-23 Nokia Corporation Apparatus, and associated method, for facilitating retransmission of data packets in a packet radio communication system that utilizes a feedback acknowledgement scheme
EP1654834A4 (en) * 2003-08-14 2012-07-04 Seiko Epson Corp Apparatus, system and method of transmitting data
US7162092B2 (en) * 2003-12-11 2007-01-09 Infocus Corporation System and method for processing image data
WO2005067635A2 (en) 2004-01-06 2005-07-28 Hava Corp. Telephone with automatic switching between cellular and voip networks
US10419996B2 (en) 2004-01-06 2019-09-17 Vasu Networks Corporation Mobile device with automatic switching between cellular and wifi networks
US8520605B2 (en) * 2004-01-06 2013-08-27 Vasu Networks Corporation Apparatus for controlling broadband access and distribution of content and communications through an access point
US8913604B2 (en) 2004-01-06 2014-12-16 Vasu Networks Corporation Access point with controller for billing and generating income for access point owner
US8078164B2 (en) 2004-01-06 2011-12-13 Vasu Networks Corporation Mobile telephone VOIP/cellular seamless roaming switching controller
US8514867B2 (en) * 2004-01-06 2013-08-20 Hava Corporation Method of determining broadband content usage within a system
US20060026181A1 (en) * 2004-05-28 2006-02-02 Jeff Glickman Image processing systems and methods with tag-based communications protocol
US7474642B1 (en) * 2004-09-15 2009-01-06 Nortel Networks Limited Signaling reliability in using high-speed shared packet data channel
US9288713B2 (en) * 2005-01-31 2016-03-15 Google Technology Holdings LLC Method and apparatus for dynamically changing modes of a reliable transport protocol
US10320989B2 (en) 2005-02-11 2019-06-11 Vasu Networks Corporation Access point with controller for billing and generating income for access point owner
US8266237B2 (en) * 2005-04-20 2012-09-11 Microsoft Corporation Systems and methods for providing distributed, decentralized data storage and retrieval
US8634422B2 (en) * 2005-08-17 2014-01-21 Qualcomm Incorporated Prioritization techniques for quality of service packet transmission over a network lacking quality of service support at the media access control layer
KR100673177B1 (en) 2005-12-15 2007-01-22 에스케이 텔레콤주식회사 Method of managing the qos for application based network
US20070258445A1 (en) * 2006-05-02 2007-11-08 Harris Corporation Systems and methods for protocol filtering for quality of service
US8516153B2 (en) * 2006-06-16 2013-08-20 Harris Corporation Method and system for network-independent QoS
US20070291768A1 (en) * 2006-06-16 2007-12-20 Harris Corporation Method and system for content-based differentiation and sequencing as a mechanism of prioritization for QOS
US20070291765A1 (en) * 2006-06-20 2007-12-20 Harris Corporation Systems and methods for dynamic mode-driven link management
US8730981B2 (en) * 2006-06-20 2014-05-20 Harris Corporation Method and system for compression based quality of service
US20080013559A1 (en) * 2006-07-14 2008-01-17 Smith Donald L Systems and methods for applying back-pressure for sequencing in quality of service
US8300653B2 (en) * 2006-07-31 2012-10-30 Harris Corporation Systems and methods for assured communications with quality of service
US20080025318A1 (en) * 2006-07-31 2008-01-31 Harris Corporation Systems and methods for dynamically customizable quality of service on the edge of a network
US20100238801A1 (en) * 2006-07-31 2010-09-23 Smith Donald L Method and system for stale data detection based quality of service
US20100241759A1 (en) * 2006-07-31 2010-09-23 Smith Donald L Systems and methods for sar-capable quality of service
CN101606373B (en) * 2006-12-29 2013-02-13 意大利电信股份公司 Communications method for a packet-switched network and network employing the method
KR100877065B1 (en) * 2007-01-12 2009-01-09 삼성전자주식회사 Method and apparatus for deciding a communication protocol
US8112687B2 (en) * 2008-01-03 2012-02-07 Ikanos Communications, Inc. Systems and methods for mitigating impulse noise
CN101222508A (en) * 2008-01-22 2008-07-16 张建中 Method, device and system for data grouping error processing and controlling
WO2009144800A1 (en) * 2008-05-29 2009-12-03 富士通株式会社 Data relay device, data relay program, data receiver, and communication system
JP2008295070A (en) * 2008-07-03 2008-12-04 Ntt Docomo Inc Adaptive radio parameter control method, qos control apparatus, base station and radio communication system
US8942104B2 (en) 2010-08-05 2015-01-27 Apple Inc. Packet classification and prioritization using a UDP checksum in a mobile wireless device
US20120033563A1 (en) * 2010-08-05 2012-02-09 Apple Inc. Packet classification and prioritization using an ip header in a mobile wireless device
JP2012095087A (en) * 2010-10-27 2012-05-17 Kyocera Corp Communication apparatus and communication method
KR20120084234A (en) 2011-01-19 2012-07-27 삼성전자주식회사 Method for delivering mmt access unit for mpeg media transport
EP2923471B1 (en) * 2012-11-26 2020-01-08 Koninklijke KPN N.V. Routing data in a network
KR102195069B1 (en) * 2014-08-06 2020-12-24 삼성전자주식회사 Packet transmitter and interface device including the same
CN108462646B (en) 2017-02-17 2020-08-25 华为技术有限公司 Message processing method and device
KR20200117131A (en) * 2019-04-03 2020-10-14 삼성전자주식회사 Method of data transmission based on change in pdcp and electronic device therefor

Citations (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5708655A (en) * 1996-06-14 1998-01-13 Telefonaktiebolaget L M Ericsson Publ Method and apparatus for addressing a wireless communication station with a dynamically-assigned address
US5778189A (en) * 1996-05-29 1998-07-07 Fujitsu Limited System and method for converting communication protocols
US5852721A (en) * 1994-06-08 1998-12-22 Hughes Electronics Corporation Method and apparatus for selectively retrieving information from a source computer using a terrestrial or satellite interface
US5978386A (en) * 1995-01-10 1999-11-02 Nokia Telecommunications Oy Packet radio system, and a terminal equipment for a packet radio system
US5987022A (en) * 1996-12-27 1999-11-16 Motorola, Inc. Method for transmitting multiple-protocol packetized data
EP0973302A1 (en) 1998-07-15 2000-01-19 Telefonaktiebolaget L M Ericsson (Publ) Device and method for reliable and low-delay packet transmission
US6041054A (en) * 1997-09-24 2000-03-21 Telefonaktiebolaget Lm Ericsson Efficient transport of internet protocol packets using asynchronous transfer mode adaptation layer two
US6112084A (en) * 1998-03-24 2000-08-29 Telefonaktiebolaget Lm Ericsson Cellular simultaneous voice and data including digital simultaneous voice and data (DSVD) interwork
US6266337B1 (en) * 1998-06-23 2001-07-24 Expand Network Ltd. Packet retransmission eliminator
US6278706B1 (en) * 1998-04-03 2001-08-21 Opuswave Networks, Inc. Wireless packet data communication apparatus and method
US6304564B1 (en) * 1996-11-29 2001-10-16 Lucent Technologies Inc. Method for transmitting messages in wireless communication system using a server process
US6320875B2 (en) * 1997-03-17 2001-11-20 At&T Corp. Methods and apparatus for providing improved quality of packet transmission in applications such as internet telephony
US6385195B2 (en) * 1997-07-21 2002-05-07 Telefonaktiebolaget L M Ericsson (Publ) Enhanced interworking function for interfacing digital cellular voice and fax protocols and internet protocols
US6400712B1 (en) * 1998-05-26 2002-06-04 Qualcomm Incorporated Fast circuit switched data architecture and method
US6421714B1 (en) * 1997-10-14 2002-07-16 Lucent Technologies Efficient mobility management scheme for a wireless internet access system

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5729544A (en) * 1994-05-09 1998-03-17 Motorola, Inc. Method for transmitting data packets based on message type
DE19640220A1 (en) * 1996-01-31 1997-08-07 Siemens Ag DECT cordless communication system with protocol-evaluating base stations
JPH10178421A (en) * 1996-10-18 1998-06-30 Toshiba Corp Packet processor, mobile computer, packet transferring method and packet processing method
US5889772A (en) * 1997-04-17 1999-03-30 Advanced Micro Devices, Inc. System and method for monitoring performance of wireless LAN and dynamically adjusting its operating parameters

Patent Citations (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5852721A (en) * 1994-06-08 1998-12-22 Hughes Electronics Corporation Method and apparatus for selectively retrieving information from a source computer using a terrestrial or satellite interface
US5978386A (en) * 1995-01-10 1999-11-02 Nokia Telecommunications Oy Packet radio system, and a terminal equipment for a packet radio system
US5778189A (en) * 1996-05-29 1998-07-07 Fujitsu Limited System and method for converting communication protocols
US5708655A (en) * 1996-06-14 1998-01-13 Telefonaktiebolaget L M Ericsson Publ Method and apparatus for addressing a wireless communication station with a dynamically-assigned address
US6304564B1 (en) * 1996-11-29 2001-10-16 Lucent Technologies Inc. Method for transmitting messages in wireless communication system using a server process
US5987022A (en) * 1996-12-27 1999-11-16 Motorola, Inc. Method for transmitting multiple-protocol packetized data
US6320875B2 (en) * 1997-03-17 2001-11-20 At&T Corp. Methods and apparatus for providing improved quality of packet transmission in applications such as internet telephony
US6385195B2 (en) * 1997-07-21 2002-05-07 Telefonaktiebolaget L M Ericsson (Publ) Enhanced interworking function for interfacing digital cellular voice and fax protocols and internet protocols
US6041054A (en) * 1997-09-24 2000-03-21 Telefonaktiebolaget Lm Ericsson Efficient transport of internet protocol packets using asynchronous transfer mode adaptation layer two
US6421714B1 (en) * 1997-10-14 2002-07-16 Lucent Technologies Efficient mobility management scheme for a wireless internet access system
US6112084A (en) * 1998-03-24 2000-08-29 Telefonaktiebolaget Lm Ericsson Cellular simultaneous voice and data including digital simultaneous voice and data (DSVD) interwork
US6278706B1 (en) * 1998-04-03 2001-08-21 Opuswave Networks, Inc. Wireless packet data communication apparatus and method
US6400712B1 (en) * 1998-05-26 2002-06-04 Qualcomm Incorporated Fast circuit switched data architecture and method
US6266337B1 (en) * 1998-06-23 2001-07-24 Expand Network Ltd. Packet retransmission eliminator
EP0973302A1 (en) 1998-07-15 2000-01-19 Telefonaktiebolaget L M Ericsson (Publ) Device and method for reliable and low-delay packet transmission

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
IBM Technical Disclosure Bulletin, vol. 38, No. 1, Jan. 1995, "Packet Fragmentation by Interface Hardware", pp. 15-16; XP000498672.
Proceedings of 8th International Symposium on Personal, Indoor and Mobile Radio Communications,-PIMRC '97, Helsinki, Finland, vol. 2, Sep. 1997, "Voice and Data Integration on TCP/IP Wireless Networks", pp. 678-682, XP002089273.
Proceedings of 8th International Symposium on Personal, Indoor and Mobile Radio Communications,—PIMRC '97, Helsinki, Finland, vol. 2, Sep. 1997, "Voice and Data Integration on TCP/IP Wireless Networks", pp. 678-682, XP002089273.
W. Richard Stephens, TCP/IP Illustrated, Volume 1, The Protocols, Addison-Wesley Professional Computing Series, pp. vii-xix and 1-576, Massachusetts.

Cited By (92)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7515540B2 (en) * 1999-01-08 2009-04-07 Telefonaktiebolaget L M Ericsson (Publ) Communication device and method
US20060050638A1 (en) * 1999-01-08 2006-03-09 Michael Meyer Communication device and method
US20050152365A1 (en) * 1999-02-25 2005-07-14 Hitachi, Ltd. Packet communication system with QoS control function
US7903667B2 (en) 1999-02-25 2011-03-08 Hitachi, Ltd. Packet communication system with QoS control function
US7463635B2 (en) * 1999-02-25 2008-12-09 Hitachi, Ltd. Packet communication system with QoS control function
US20090080424A1 (en) * 1999-02-25 2009-03-26 Takeki Yazaki Packet communication system with qos control function
US7489647B2 (en) * 1999-07-31 2009-02-10 Lg Information & Communications, Ltd. Method for performing cell broadcasting and communication system using the same
US20040038691A1 (en) * 1999-07-31 2004-02-26 Lg Information & Communications, Ltd. Method for performing cell broadcasting and communication system using the same
US20030103515A1 (en) * 1999-10-26 2003-06-05 Brown James M. Method and apparatus for efficient data transmission control in a wireless voice-over-data communication system
US7522631B1 (en) 1999-10-26 2009-04-21 Qualcomm, Incorporated Method and apparatus for efficient data transmission control in a wireless voice-over-data communication system
US7609716B2 (en) * 1999-10-26 2009-10-27 Qualcomm Incorporated Method and apparatus for efficient data transmission control in a wireless voice-over-data communication system
US6987777B1 (en) * 1999-12-02 2006-01-17 Nortel Networks Ltd Priority forwarding in a communication system
US20030070129A1 (en) * 1999-12-08 2003-04-10 Carsten Ball Method for packet-oriented data transmission in a radio communication system
US20010043615A1 (en) * 2000-02-26 2001-11-22 Park Jeong-Hoon Apparatus for transmitting/receiving a bit stream in a network and method therefor
US7616661B2 (en) * 2000-02-26 2009-11-10 Samsung Electronics Co., Ltd. Apparatus for transmitting/receiving a bit stream in a network and method therefor
US6944802B2 (en) * 2000-03-29 2005-09-13 The Regents Of The University Of California Method and apparatus for transmitting and receiving wireless packet
US20020026614A1 (en) * 2000-03-29 2002-02-28 Dong-Seek Park Method and apparatus for transmitting and receiving wireless packet
US20070195714A1 (en) * 2000-04-13 2007-08-23 Schales Douglas L Network data packet classification and demultiplexing
US7177289B2 (en) 2000-07-12 2007-02-13 Juniper Networks, Inc. Facilitating communications between a radio device and a terminal
US20060077948A1 (en) * 2000-07-12 2006-04-13 Hiroshi Asahina Facilitating communications between a radio device and a terminal
US20020015417A1 (en) * 2000-07-12 2002-02-07 Nec Corporation Communication system between a radio communication network and a connectionless network and interworking apparatus for use in the communication system
US6982963B2 (en) * 2000-07-12 2006-01-03 Juniper Networks, Inc. Communication system between a radio communication network and a connectionless network and interworking apparatus for use in the communication system
US7031257B1 (en) * 2000-09-22 2006-04-18 Lucent Technologies Inc. Radio link protocol (RLP)/point-to-point protocol (PPP) design that passes corrupted data and error location information among layers in a wireless data transmission protocol
US20060156198A1 (en) * 2000-09-22 2006-07-13 Lucent Technologies Inc. Complete user datagram protocol (CUDP) for wireless multimedia packet networks using improved packet level forward error correction (FEC) coding
US7151754B1 (en) * 2000-09-22 2006-12-19 Lucent Technologies Inc. Complete user datagram protocol (CUDP) for wireless multimedia packet networks using improved packet level forward error correction (FEC) coding
US7039025B1 (en) * 2000-09-29 2006-05-02 Siemens Communications, Inc. System and method for providing general packet radio services in a private wireless network
US20050041599A1 (en) * 2000-12-01 2005-02-24 Arthur Zavalkovsky Method and apparatus for maintaining consistent per-hop forwarding behavior in a network using network-wide per-hop behavior definitions
US7027410B2 (en) * 2000-12-01 2006-04-11 Cisco Technology, Inc. Method and apparatus for maintaining consistent per-hop forwarding behavior in a network using network-wide per-hop behavior definitions
US6839327B1 (en) * 2000-12-01 2005-01-04 Cisco Technology, Inc. Method and apparatus for maintaining consistent per-hop forwarding behavior in a network using network-wide per-hop behavior definitions
US20030183691A1 (en) * 2001-02-08 2003-10-02 Markku Lahteenmaki Smart card reader
US6942147B2 (en) * 2001-02-08 2005-09-13 Nokia Corporation Smart card reader
US20030235206A1 (en) * 2001-02-15 2003-12-25 Tantivy Communications, Inc. Dual proxy approach to TCP performance improvements over a wireless interface
US20020124095A1 (en) * 2001-03-02 2002-09-05 Sultan Israel Daniel Apparatus and method for sending point-to-point protocol over ethernet
US20020141370A1 (en) * 2001-03-12 2002-10-03 Nischal Abrol Method and apparatus for providing multiple quality of service levels in a wireless packet data services connection
AU2002247311B2 (en) * 2001-03-12 2007-03-15 Qualcomm Incorporated Method and apparatus for providing multiple quality of service levels in a wireless packet data services connection
US8531957B2 (en) 2001-03-12 2013-09-10 Qualcomm Incorporated Method and apparatus for providing multiple quality of service levels in a wireless packet data services connection
US20050259687A1 (en) * 2001-03-12 2005-11-24 Nischal Abrol Method and apparatus for providing multiple quality of service levels in a wireless packet data services connection
AU2007202707B2 (en) * 2001-03-12 2008-09-11 Qualcomm Incorporated Method and apparatus for providing multiple quality of service levels in a wireless packet data services connection
US20100284341A1 (en) * 2001-03-12 2010-11-11 Qualcomm Incorporated Method and apparatus for providing multiple quality of service levels in a wireless packet data services connection
US7778287B2 (en) * 2001-03-12 2010-08-17 Qualcomm Incorporated Method and apparatus for providing multiple quality of service levels in a wireless packet data services connection
US7096261B2 (en) * 2001-03-12 2006-08-22 Qualcomm Incorporated Method and apparatus for providing multiple quality of service levels in a wireless packet data services connection
US8370525B2 (en) * 2001-03-30 2013-02-05 Intel Corporation Transmitting new data format under existing infrastructure
US20020143994A1 (en) * 2001-03-30 2002-10-03 Jiming Sun Transmitting new data format under existing infrastructure
US20020142765A1 (en) * 2001-03-30 2002-10-03 Rhoads Monte J. Network appliance wireless configuration interface
US20040185859A1 (en) * 2001-07-29 2004-09-23 Yuval Barkan Cellular network system and method
US20040190523A1 (en) * 2001-08-22 2004-09-30 Christina Gessner Method and radio sation for transmitting data packets in a radio-communication system
US7742483B2 (en) * 2001-08-22 2010-06-22 Siemens Aktiengesellschaft Method and radio sation for transmitting data packets in a radio-communication system
US20050180464A1 (en) * 2002-10-01 2005-08-18 Adondo Corporation Audio communication with a computer
US20040078372A1 (en) * 2002-10-18 2004-04-22 Nokia Corporation Method and system for recalling details regarding past events
US7472135B2 (en) * 2002-10-18 2008-12-30 Nokia Corporation Method and system for recalling details regarding past events
US7525994B2 (en) * 2003-01-30 2009-04-28 Avaya Inc. Packet data flow identification for multiplexing
US20040151206A1 (en) * 2003-01-30 2004-08-05 Scholte Alexander Martin Packet data flow identification for multiplexing
US8036122B2 (en) * 2003-04-03 2011-10-11 Alcatel Lucent Initiation of network treatment for data packet associated with real-time application different from network treatment applicable to data packet non-associated with the real-time application
US20040196786A1 (en) * 2003-04-03 2004-10-07 Subhasis Laha Initiation of network treatment for data packet associated with real-time application different from network treatment applicable to data packet non-associated with the real-time application
US10313306B2 (en) 2003-07-29 2019-06-04 Marlow Technologies, Llc Broadband access for virtual private networks
US9467373B2 (en) 2003-07-29 2016-10-11 Marlow Technologies, Llc Broadband access for virtual private networks
US8520681B2 (en) 2003-07-29 2013-08-27 At&T Intellectual Property I, L.P. Broadband access for virtual private networks
US8243732B2 (en) * 2003-07-29 2012-08-14 At&T Intellectual Property I, L.P. Broadband access for virtual private networks
US20090028155A1 (en) * 2003-07-29 2009-01-29 At&T Intellectual Property I, L.P. Broadband access for virtual private networks
US8942240B2 (en) 2003-07-29 2015-01-27 Marlow Technologies, Llc Broadband access for virtual private networks
US11240206B2 (en) 2003-07-29 2022-02-01 Marlow Technologies, Llc Broadband access for virtual private networks
US20050063392A1 (en) * 2003-09-04 2005-03-24 Ntt Docomo, Inc. Packet-priority control apparatus and method thereof
US7668150B2 (en) * 2003-09-04 2010-02-23 Ntt Docomo, Inc. Packet-priority control apparatus and method thereof
US7450568B2 (en) 2003-12-05 2008-11-11 Cisco Technology, Inc. System and method for managing a VolP network
US20050122958A1 (en) * 2003-12-05 2005-06-09 Shim Choon B. System and method for managing a VoIP network
US20050135423A1 (en) * 2003-12-23 2005-06-23 Xiaodong Chen Method and system for RLP optimization
US7197026B2 (en) * 2003-12-23 2007-03-27 Nokia Corporation Method and system for RLP optimization
US20050216625A1 (en) * 2004-03-09 2005-09-29 Smith Zachary S Suppressing production of bus transactions by a virtual-bus interface
US7065603B2 (en) * 2004-03-29 2006-06-20 Hewlett-Packard Development Company, L.P. Virtual bus interface production of header-type fields from data-type fields
US20050216638A1 (en) * 2004-03-29 2005-09-29 Smith Zachary S Virtual bus interface production of header-type fields from data-type fields
US20050228926A1 (en) * 2004-04-05 2005-10-13 Smith Zachary S Virtual-bus interface and associated system and method
US7848236B2 (en) * 2004-08-10 2010-12-07 Nokia Corporation Differentiation of quality classes to different PDUs with support for multiple terminals
US20060034331A1 (en) * 2004-08-10 2006-02-16 Nokia Corporation Differentiation of quality classes to different PDUs with support for multiple terminals
US7680100B1 (en) 2004-09-30 2010-03-16 Avaya Inc. Internet protocol appliance manager
US8321766B2 (en) * 2006-03-20 2012-11-27 Fujitsu Limited IP-data transmitting apparatus and IP-data transmitting method
US20070220404A1 (en) * 2006-03-20 2007-09-20 Fujitsu Limited IP-data transmitting apparatus and IP-data transmitting method
US20070253270A1 (en) * 2006-04-28 2007-11-01 Hynix Semiconductor Inc. Semiconductor memory device performing self refresh operation
US20080205309A1 (en) * 2006-10-04 2008-08-28 Nokia Corporation Virtual adaptation layer for wireless communication
US9049690B2 (en) * 2006-12-27 2015-06-02 Kyocera Corporation Communication system, wireless communication terminal, communication method, wireless communication method, wireless communication apparatus and control method thereof
US20110044210A1 (en) * 2006-12-27 2011-02-24 Kyocera Corporation Communication System, Wireless Communication Terminal, Communication Method, Wireless Communication Method, Wireless Communication Apparatus and Control Method Thereof
US8483142B2 (en) 2007-02-07 2013-07-09 Wichorus, Inc. Method and apparatus for managing backhaul links in a communication network
US20080186858A1 (en) * 2007-02-07 2008-08-07 Rehan Jalil Method and apparatus for managing backhaul links in a communication network
US7933284B2 (en) 2007-03-30 2011-04-26 International Business Machines Corporation Method and apparatus for improving SIP server performance
US8687482B2 (en) * 2007-09-07 2014-04-01 Wichorus, Inc. Apparatus and method for controlling traffic flow in backhaul link in wireless communication network
US9084154B2 (en) 2007-09-07 2015-07-14 Wichorus Inc. Apparatus and method for controlling traffic flow in backhaul link in wireless communication network
US20090067333A1 (en) * 2007-09-07 2009-03-12 Wichorus Inc. Apparatus and method for controlling traffic flow in backhaul link in wireless communication network
US8737315B2 (en) * 2008-02-29 2014-05-27 Fujitsu Limited Communication apparatus and allocation determining method
US20090219877A1 (en) * 2008-02-29 2009-09-03 Fujitsu Limited Communication apparatus and allocation determining method
US20140334442A1 (en) * 2013-05-08 2014-11-13 Qualcomm Incorporated Method and apparatus for handover volte call to umts ps-based voice call
US9369926B2 (en) * 2013-05-08 2016-06-14 Qualcomm Incorporated Method and apparatus for handover VoLTE call to UMTS PS-based voice call
US11128739B2 (en) * 2018-12-24 2021-09-21 Verizon Patent And Licensing Inc. Network-edge-deployed transcoding methods and systems for just-in-time transcoding of media data
US20220346111A1 (en) * 2019-09-29 2022-10-27 Sony Group Corporation Electronic device and method in wireless communication system

Also Published As

Publication number Publication date
US20040039833A1 (en) 2004-02-26
EP1097548B1 (en) 2005-12-07
JP4334770B2 (en) 2009-09-30
AU756050B2 (en) 2003-01-02
CN1188991C (en) 2005-02-09
WO2000004680A1 (en) 2000-01-27
CA2337050C (en) 2009-12-01
ATE312461T1 (en) 2005-12-15
CA2337050A1 (en) 2000-01-27
DE69928812D1 (en) 2006-01-12
EP0975123A1 (en) 2000-01-26
DE69928812T2 (en) 2006-08-24
JP2002521866A (en) 2002-07-16
CN1318241A (en) 2001-10-17
EP1097548A1 (en) 2001-05-09
US7382763B2 (en) 2008-06-03
AU4904199A (en) 2000-02-07

Similar Documents

Publication Publication Date Title
US6697352B1 (en) Communication device and method
US6577596B1 (en) Method and apparatus for packet delay reduction using scheduling and header compression
EP1188325B1 (en) Controlling pdp contexts in mobile stations
RU2296423C2 (en) Method and device affording desired levels with plurality of servicing quality coefficients in wireless data burst transmission connections
FI107674B (en) Procedure for optimizing data transmission in a packet switched wireless communication system
FI114132B (en) Supporting the quality of data transmission through wireless data transmission
EP1614258B1 (en) Method and system for rate control service in a network
CA2257319C (en) Dynamic radio link adaptation
US6845105B1 (en) Method and apparatus for maintaining sequence numbering in header compressed packets
JP3863334B2 (en) Information transfer method, communication apparatus, and data communication system
EP1134942A1 (en) Method and arrangement for control of non real-time application flows
WO1999051055A2 (en) A method in packet data transmission between a wireless terminal and a mobile ip router
US7706276B2 (en) Systems and methods for wireless communications
GB2341059A (en) Internet protocol flow detection
US20050102412A1 (en) Transmission performance of a transport layer protocol connection
US20060198376A1 (en) Communication device for IP network
US7330439B1 (en) Packet data transmission in third generation mobile system
EP0973302A1 (en) Device and method for reliable and low-delay packet transmission
KR101333083B1 (en) The Method and Apparatus for classification according to the Service flow of the IP packet
PACKETS 1” ME?“UP LAYER n
COMMAND et al. Related US. Application Data (Continued)(63) Continuation of application No. 09/353,853,? led on Primary Examinel’4chi Pham
Honkasalo et al. UMTS Quality of Service

Legal Events

Date Code Title Description
AS Assignment

Owner name: TELEFONAKTIEBOLAGET L M ERICSSON (PUBL), SWEDEN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LUDWIG, REINER;KHAN, FAROOQ;RATHONYI, BELA;REEL/FRAME:010298/0525

Effective date: 19990909

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

FPAY Fee payment

Year of fee payment: 8

FPAY Fee payment

Year of fee payment: 12