[go: up one dir, main page]

EP2099179B1 - Methode et systeme de negotiation de debit dans un réseau - Google Patents

Methode et systeme de negotiation de debit dans un réseau Download PDF

Info

Publication number
EP2099179B1
EP2099179B1 EP09007414A EP09007414A EP2099179B1 EP 2099179 B1 EP2099179 B1 EP 2099179B1 EP 09007414 A EP09007414 A EP 09007414A EP 09007414 A EP09007414 A EP 09007414A EP 2099179 B1 EP2099179 B1 EP 2099179B1
Authority
EP
European Patent Office
Prior art keywords
message
rnc
rate
mobile entity
proxy
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
EP09007414A
Other languages
German (de)
English (en)
Other versions
EP2099179A1 (fr
Inventor
Justus Petersson
Magnus Westerlund
Svetlana Chermiakina
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
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of EP2099179A1 publication Critical patent/EP2099179A1/fr
Application granted granted Critical
Publication of EP2099179B1 publication Critical patent/EP2099179B1/fr
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
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/19Flow control; Congestion control at layers above the network layer
    • H04L47/193Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/26Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H04L47/263Rate modification at the source after receiving feedback
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0273Traffic management, e.g. flow control or congestion control adapting protocols for flow control or congestion control to wireless environment, e.g. adapting transmission control protocol [TCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/16Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18Negotiating wireless communication parameters
    • H04W28/22Negotiating communication rate
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04Registration at HLR or HSS [Home Subscriber Server]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/06Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless

Definitions

  • the present invention relates to communications systems and methods, and more particularly, to controlling transmission of data bits in a bit transfer session.
  • UDP User Datagram Protocol
  • TCP Transmission Control Protocol
  • UDP is a connectionless protocol without flow control mechanisms
  • TCP is a connection oriented protocol with flow control mechanisms that provides for reliable data transfer between two hosts.
  • the bandwidth over the air-interface is a scarce and limited resource. Therefore, it is of interest to make efficient use of available radio resources.
  • the bandwidth that is available for a radio connection in a mobile communication network may vary quickly due to changes in the characteristics of the air-interface caused by e.g. fading dips or shadowing, or due redistribution of the assigned bandwidth to the users in a cell.
  • the limited bandwidth over the air-interface and the changing bandwidth may make it difficult to provide acceptable quality-of-service (QoS) to an end-user residing in a mobile system.
  • QoS quality-of-service
  • the limited bandwidth may for instance result in long latencies which the end-user experiences as annoying.
  • WO 00/51313 discloses setting-up of voice calls via a called number translation point which performs a called party number translation.
  • Embodiments of the present invention relates to addressing issues and "setting up" a rate control service.
  • embodiments of the present invention set up a flow control or rate control mechanism for a bit transfer session between a client in a mobile system and an application server by means of a transport.
  • the rate control mechanism may be associated with a number of rate control parameters.
  • Embodiments of the invention make use of feedback information from a radio resource managing entity to set an d update flow control parameters throughout the session. Once the rate control mechanism is configured or "set up" a radio resource managing entity can communicate with a network entity to optimize rate control parameters, which allows for enhanced QoS and efficient use of available radio resources.
  • One advantage of the present invention is that it "sets up" rate control services so that network entities can optimally balance the offered traffic over the air-interface with the back-end for person-to-content and person-to-person services over the packet switched domain leading to a better utilization of scarce radio resources.
  • Another advantage of some of the embodiments of the present invention is that since the feedback information that is used for controlling the rate control parameters may be provided continuously throughout the session from the radio resource managing entity which is located in the radio access network, the flow control parameters may be updated based on current information. This allows for better parameter settings compared to prior art solutions where the flow control parameters are set only once at the beginning of the session based on historical data from previous sessions. Since the feedback information used in the present invention is communicated from the radio access network to the network entity controlling the flow control parameters the feedback information will not be subjected to the as much delay as in the client-centric solutions discussed above. The radio access network detects changes in the available bandwidth of the session faster than the client does and there is no need to communicate the feedback information over the air-interface.
  • the continuous monitoring and updating of flow control parameters allows for good QoS throughout the entire session and not just at the beginning of the session.
  • parameter settings are not updated during the session, there is a risk that the QoS may deteriorate during the session if the radio conditions experienced by the session changes. Radio conditions may change very rapidly and thus it is more important to update parameter settings of sessions involving an air interface than those of sessions which are entirely based on wired connections.
  • a further advantage of some embodiments of the present invention is that they makes use of network feedback for each session separately which is used to update the flow control parameters of each session individually.
  • the parameter settings may be specifically adapted to optimize the QoS for each session.
  • flow control is handled for groups of sessions. Even though the prior art solutions allows few flow control decisions compared to the invention, these solutions may lead to poor quality-of-service for a particular client who is locally experiencing radio conditions that are much worse than those of other clients in the same group.
  • an additional advantage of the present invention is that the sizes of buffers in the radio resource managing entity may be minimized.
  • the present invention is applicable to person-to-content (P2C) and person-to-person (P2P) packet switched services in a mobile system, and particularly to such services which are based on a transport protocol with a flow control mechanism.
  • Such services comprise packet communication between a user equipment of an end-user and an application server.
  • the mobile system includes a mobile network such as a WCDMA, CDMA2000, Wireless LAN or GPRS network in which the user equipment resides.
  • An example of a transport protocol with a flow control mechanism is the TCP.
  • the flow control mechanism of the TCP comprises a number of flow control parameters as is well known to a person skilled in the art. Examples of TCP flow control parameters are window size and segment size.
  • the transmission of data bits over a TCP connection may be controlled by means of changing the TCP flow control parameters.
  • the available bandwidth over the air interface will normally be the limiting factor on the bit rate of the session.
  • the characteristics of the air-interface e.g. fading dips and shadowing, may have negative consequences for the end-user. This is especially true for applications that use the TCP protocol as a transport bearer. For instance, a long latency over the air-interface may trigger the TCP congestion avoidance mechanism, leading to less bandwidth for the session and resulting in a very lousy performance for the end-user.
  • the end-user will temporarily get increased bandwidth over the air-interface, this may most likely not speed up the TCP connection to the same extent, implying that scarce radio resources will not be utilised. Since the radio resources on the air interface are scarce resources which it is of interest to utilize as efficiently as possible, a more efficient use of the available radio resources will most likely improve the quality-of-service of the end-users.
  • Fig. 1 illustrates schematically a communication session between a client in user equipment 102 and an application server 104 according to prior art.
  • the application server 104 is a Web Server.
  • the session is set up by means of a TCP link 106 between the client 102 and the application server 104.
  • the client When the client is browsing or downloading information from the application server 104, the client acknowledges the reception of data which thereby indicates the quality of the reception.
  • the application server 104 uses this information from the acknowledgments to adapt TCP transmission parameters, such as e.g. window size or segment size, to the transmission conditions over the TCP link.
  • TCP transmission parameters such as e.g. window size or segment size
  • a problem with the approach in Fig. 1 is that when the transmission link includes a radio connection there is a risk that bad radio connection conditions including many retransmissions are misinterpreted by the application server 104 as congestion, thereby triggering the TCP congestion avoidance mechanism. Also, the radio conditions may change very fast, but the feedback in the form of acknowledgements comes relatively late, which further reduces the ability of the server to adequately react to changed radio transmission conditions. These are drawbacks that occur since the TCP transmission mechanism was not designed for radio transmission.
  • Fig. 2 is a schematic block diagram illustrating the basic principles of a communication session where one aspect of the present invention is used.
  • a communication session is set up between the client 102 and the application server 104 via a proxy 112 by means of TCP connections 106a and 106b.
  • the TCP connection 106b involves transmission over a radio link in a mobile network 114.
  • the mobile network reports network feedback data regarding the quality-of-service of the radio link transmission to the proxy.
  • the proxy uses the network feedback data to change TCP parameter settings, such as TCP window size and segment size, of the TCP connection 106b.
  • the network feedback may also be used to decide how to acknowledge reception to the application server over the TCP connection 106a.
  • the network feedback data that is reported to the proxy is information about the bandwidth that the radio resource managing entity of the mobile network has decided that the session is allowed to use over the air-interface.
  • Fig. 3 is a schematic diagram illustrating a comparison of the throughput rate using arrangements according to Fig. 1 and Fig. 2 respectively.
  • the rectangular curve 120 illustrates the bandwidth that the radio resource managing entity of the mobile network has decided that the session is allowed to use over the air-interface.
  • Curve 116 illustrates the throughput curve of the prior art arrangement in Fig. 1 and the bold curve 118 illustrates the throughput curve of the arrangement according to the invention in Fig. 2 .
  • the curve 116 illustrates that the transmission rate first increases exponentially, until the maximum available bit rate over the air interface has been reached.
  • the client starts reporting "Not received", which is interpreted by the application server 104 in Fig. 1 as congestion.
  • the application server applies the congestion avoidance mechanism whereby the transmission rate is reduced substantially.
  • the application server starts to very slowly increase the transmission rate linearly. This behaviour of the application server may not be in conformity with the actual situation over the radio link.
  • the proxy 112 may take more adequate and faster measures since it receives radio link information earlier - which provides a more accurate description of the radio transmission conditions.
  • An increase in the available bandwidth over the air interface will quickly result in greater throughput when the arrangement in Fig. 2 is used.
  • Fig. 2 illustrates use of the invention for a session that is set up via a proxy and two TCP connections 106a and 106b
  • the use of a proxy is not essential to the invention.
  • the invention may be implemented such that the network feedback is provided directly to the application server.
  • the application server can then use the network feedback to adequately adapt the TCP parameters of the session.
  • P2C Person-to-Content
  • aspects of the present invention are also equally applicable in Person-to-Person (P2P) services.
  • Fig. 4a illustrates an embodiment of the present invention in a UMTS system 120 in a Person-to-Content (P2C) scenario.
  • the system includes a radio access network 122 comprising a number of Radio Base Stations (RBSs) 124 and at least one Radio Network Controller (RNC) 126.
  • the system further includes a Serving GPRS Support Node (SGSN) 128 and a Gateway GPRS Support Node (GGSN) 130, which are nodes in a Core Network (CN) 132 that provides a connection between the radio access network 122 and a Service Network (SN) 134.
  • the Service Network 134 includes the application server 104 and the proxy 112.
  • the proxy may be in communication with a Service Network Session Database (SNSD) 136, and an external IP network 138.
  • SNSD Service Network Session Database
  • the present invention provides improved means for controlling the transmission rate of the session, which allows for end-user quality-of-service optimization.
  • Information about the allowed bandwidth over the air-interface used for the session may be sent from the RNC 126 to the proxy 112.
  • the proxy 112 has access to the currently allowed bit rate over the air-interface, the proxy has the ability to set the TCP flow control parameters such as e.g. the segment/window sizes to optimally fit the radio resource situation.
  • the proxy 112 may have the capabilities of optimising the end-user's quality-of-service on the basis of the obtained bandwidth information from the RNC 126 and its own internal algorithms.
  • the RNC 126 may be pre-configured to manage the RC service.
  • the RNC 126 may be hard-coded or configured with data that is necessary for the service by a configuration tool 140. Additionally, the RNC 126 may be partially configured with the aid of the user equipment (UE), or the application server, or the application server proxy, or the Media Gateway. Typically, the receiver of the Rate Control indications is the proxy 112.
  • a parameter setting unit which updates session parameters based on the network feedback, may be adapted to be able to receive and interpret the network feedback and to be able to adapt the parameters based on the received network feedback. It will be apparent to the person skilled in the art how the present invention may be implemented using known hardware and software means. The network feedback mechanism according to the present invention may be implemented using a separate protocol created for this purpose.
  • the Rate Control service may be setup for every media stream in the SDP description (e.g., one RC service setup for the speech stream and one RC service setup for the video stream), all media stream in the SDP description as a whole, or any combination thereof.
  • the SNSD 136 may be connected to the proxy 112 and communicates the bandwidth information from the RNC 126 to the proxy 112. In some embodiments, the SNSD 136 may be arranged store the bandwidth information from the RNC 126.
  • PDP packet data protocol
  • this PDP context includes among other information an access point name (APN).
  • APN gives a logical connection between the UE 102 and the proxy 112.
  • the proxy 112 or the SNSD 136 may, for instance, store the following information about the UE 102:
  • a bit transfer session may be set up between the application server 104 in the service network 134 and a client on a User Equipment (UE) 102 by means of connections 106a, 106b that pass through the proxy 112, the CN 132, and the radio access network 122.
  • the session may be set up between the UE 102 and an application server 104 in an external network 138 with which the proxy communicates.
  • the connections 106a, 106b may for instance be TCP connections or connections based on another type of transport protocol with some kind of flow control mechanism.
  • the Open System Interconnection (OSI) reference model divides communication between network devices into seven smaller “layers.” Each layer has a predetermined set of functions which are performed for the communication to occur.
  • Fig. 4b illustrates the OSI reference model establishing a communication link from a node, for example UE 102 through intermediary nodes (such as the RNC 126, the SGSN 128, and the GGSN 130) to the application server 104.
  • intermediary nodes such as the RNC 126, the SGSN 128, and the GGSN 130
  • An application layer 141 identifies and establishes the availability of intended communication partners, synchronizes cooperating applications, and establishes agreement on procedures for error recovery and control of data integrity.
  • a presentation layer 142 is "below" the application layer 141 and ensures that information sent by the application layer of one system will be readable by the application layer of another system.
  • a session layer 143 lies below the presentation layer 142 and establishes, manages, and terminates sessions between applications. Sessions consist of dialogue between two or more presentation entities.
  • a transport Layer 144 Below the session layer 143 is a transport Layer 144.
  • the transport layer 144 the transport layer provides mechanisms for the establishment, maintenance, and orderly termination of virtual circuits and information flow control.
  • a network layer 145 is below the transport layer.
  • the network layer 145 is a layer that provides connectivity and path selection between two end systems that may be located on geographical diverse subnetworks.
  • a link layer 146 provides transit of data across a physical link In so doing, the link layer 146 is concerned with physical (as opposed to network, or logical) addressing, network topology, line discipline (how end systems will use the network link), error notification, ordered delivery of frames, and flow control.
  • a physical layer 147 Below the link layer 146, is a physical layer 147 which defines the electrical, mechanical, procedural, and functional specifications for activating, maintaining, and deactivating the physical link between end systems.
  • the boundary between the session layer 143 and the transport layer 144 is generally thought of as the boundary between application-layer protocols and lower-layer protocols. Whereas the application, presentation, and session layers are concerned with application issues, the lower four layers are typically concerned with data transport issues.
  • the RNC 126 can detect changed system conditions over the UE-RNC link, which occurs at the physical level 147.
  • the RNC 126 may update the proxy 112 about state changes over the UE-RNC link (e.g., wireless link).
  • the state change information may then be used by the application server 104 to balance the data flow originating from itself towards the UE 102 to match the available capacity over the UE-RNC link.
  • the state information from the RNC to the proxy 112 may be transparent, i.e. invisible, to the SGSN 128 and the GGSN 130).
  • the RNC needs to know the address of the application server 112 so the RNC can send the state information to the application server 104.
  • Fig. 5 illustrates a general call flow procedure 150 using TCP adaptation wherein the TCP link between the UE and the application server has been split in two parts: (1) between the application server 104 and the proxy 112, and (2) between the proxy 112 and the UE 102.
  • the initial conditions for the example illustrated in Fig. 5 are these:
  • the application server sends payload at a certain bit rate according to the network protocol, such as TCP mechanisms.
  • the proxy 112 Due to limitations with the air-interface, the proxy 112 is not allowed to relay the incoming payload at the same pace as it arrives. Therefore, the proxy 112 temporarily stores the incoming payloads in a cache (not shown) and acknowledges the Application Server by sending acknowledgements (ACKs) as if the payloads had been received by the client By doing so one decreases the risk that the TCP congestion control mechanism will be employed. At the same time one minimises the total download time for the requested object/file.
  • the RNC can notify the proxy, who then notifies the application server so that a new bit transfer rate can be employed.
  • the procedure 150 is a "snapshot" of the behaviour to the network feedback based rate adaptation according to one aspect of the present invention. During a whole session the procedure 150 may be employed many times as the allowed bit rate of the session over the air interface varies.
  • the RNC 126 may be adapted so that it can communicate the network feedback according to the present invention to another unit, such as the proxy 112 or the application server 104.
  • the RNC 126 may be informed about the proxy's 112 IP address upon i) configuration or ii) session set-up. By doing so, the RNC 126 can send information the about valid bit rate directly to the proxy 112 without any interrogation from an intermediate node.
  • Fig. 6 is a call flow diagram illustrating a procedure 170 that is similar to the procedure 150 described with reference to Fig. 5 .
  • the procedure 170 illustrates how the addressing issue is solved when the RNC is configured to send rate control indicators for a specific session.
  • the procedure 170 configures the RNC to send bandwidth (i.e., rate control) indicators to the proxy via the GGSN for a specific traffic class.
  • the application server 104 sends data at a certain bit rate according to the network protocol mechanisms.
  • the RNC 126 determines that a new bit rate is possible and sends an IP message towards the Proxy 112.
  • the Proxy 112 does not know which session (i.e., which UE) the Rate Control message applies, the procedure needs to resolve the UE's IP address and Port number.
  • the resolution may be accomplished via a GTP-U Tunnel Endpoint Identifier in a T-PDU message and TFT filter mapping.
  • the GGSN may employ procedures to determine the UE's IP address (or alternatively attach the MSISDN or IMSI to the message). In the latter case, the MSISDNJIMSI will be resolved and mapped to a UE IP address by the Service Network's session database, which has an interface to the Proxy (not shown in the Fig. 6 ).
  • the RNC provides the UE's IP-address and port number in the rate control feedback message 174. Therefore, the RNC first determines the UE's IP-address (or alternatively, attach the MSISDN or IMSI number to the message. In the latter case, the MSISDN/IMSI will be resolved and mapped to the UE IP address by the service network's session database). Two methods of determining the UE's IP-address are discussed in relation to Figs. 7 and 8 .
  • Fig. 7 illustrates a "sniffing" procedure 190 at the PDP context setup so that the RNC can initiate Rate Control services.
  • "Sniffing" as used in this disclosure means that the RNC listens to the user data traffic from UE and intercepts messages that are marked appropriately. For example there may be a rate control identification (RC ID) field in the lu UP protocol or destination port number in IP header which alerts the RNC that such messages may be subject to a rate control service.
  • RC ID rate control identification
  • the GGSN sends Radius Accounting Message to the Proxy.
  • the RADIUS Account Message includes UE IP-address, MSISDN and optionally the IMSI number.
  • the Proxy sends a rate control initialization message towards the UE's IP address and a specific RC Port number over the GTP-U layer.
  • the data in the RC Init message contains, among other things: the UE's and Proxy's IP addresses and port numbers).
  • the RNC sniffs for (e.g., examines) messages directed towards this specific RC Port number. Once the RNC has sniffed such message, it binds the IP-address with the corresponding RAB identifier by using the GTP Tunnel Identifier. The RNC may then send a rate control feedback message upon channel containing rate changes towards the IP address and port number it sniffed at the PDP context activation.
  • Fig. 8 illustrates another "sniffing" procedure 200 in which the RNC determines the UE's IP address in a more flexible manner than in the procedure 190 ( Fig. 7 ).
  • the traffic does not go through a specific Proxy.
  • the UE sends an http request to the proxy to initiate a transfer request.
  • a TCP response is returned towards the UE.
  • the TCP response may be carried in one or several TCP packets. (The response could also be carried in a UDP message in case of "streaming over UDP").
  • the RNC (or alternatively, the BSC) sniffs the packets and determines the source and destination IP addresses and Port numbers of the packets.
  • the RNC can then send a Rate Control Feedback message back to the source IP address and Port number, which where previously discovered.
  • the UE IP address and Port number may then serve as identity and may therefore may also be included in the message.
  • Fig. 9 illustrates an example where the UE configures the RNC with the needed parameters for the rate control service in a PDP context establishment.
  • the proxy adds the specific rate control parameters to the RTSP/SDP protocol.
  • the RNS may or may not have an IP address of its own.
  • a Proxy and an Application Server will be used to illustrate the principles of the underlying procedure.
  • a specific identity has been added in order to implement the RC Rate Control service.
  • the RC ID i.e., the RC ID
  • the RC IP address and RC Port number correspond to the Proxy's IP address and Port number.
  • NATs Network Address Translators
  • a special identity for the Rate Control service is used because the UE IP address and Port number are operator specific (i.e., they are only locally known) and cannot be used by the Server as Rate Control service identifier.
  • the set-up parameters may be included in the HTTP header by the Proxy or the Server.
  • Another alternative, which maybe more suited for general TCP traffic is to preconfigure the UE with the RC IP address and Port number.
  • Fig. 10 illustrates a procedure 250 where the proxy configures the RNC with the required parameters for the rate control service upon PDP context establishment.
  • a Proxy and an Application Server will be used to illustrate the underlying procedure.
  • the initial conditions for the example illustrated in Fig. 10 are these: the RNC is not associated with an IP address and the UE is unaware of the RC service. Furthermore, the RNC and the Proxy may be pre-configured by means of the configuration tool 140 with RC port number. This RC port number is not used by the Proxy as a source port number for the RC messages. The RNC uses the RC port number to "sniff' or single out RC messages, i.e. the messages that have source port number equal to the RC port number.
  • the UE After the request is initiated (which in this example, occurs at the application level with the RTSP protocol), the UE establishes the secondary PDP context TFT packet filters in such a way that it includes only the user data flow (because the UE is unaware of the RC service [see 3GPP TS 23.060]).
  • the proxy In order to initialize the RNC, the proxy sends an initialization message whose IP/UDP header contains the UE IP address and user data port number as destination address and port.
  • the source port is the RC port number (pre-configured) and source IP address is the Proxy's IP address.
  • the initialization message contains the following parameters:
  • the GGSN maps the incoming initialization message to the PDP context carrying the user data flow (i.e. the PDP context carrying the data to be controlled) because the IP address and destination port number of the RC message equal the values in the user data.
  • the RNC "sniffs" all the incoming traffic of that particular user and intercepts the packets that have the RC port listed as the source port (i.e., the rate control messages).
  • the RNC is able to bind the RC message with correct Radio Access Bearer (RAB) because the RC message has arrived from that particular RAB.
  • RAB Radio Access Bearer
  • RNC sends the RC Response message to the RC IP address and RC port number (i.e. to the Proxy).
  • This message contains initial bit rate and RC ID.
  • the Proxy uses the RC ID for binding the rate control message to the RTSP session.
  • Fig. 11 Illustrates another procedure 290 where the proxy sets up the RNC with parameters for rate control service.
  • the RNC has an IP address.
  • the initial conditions for the procedure 290 are these:
  • the proxy may retrieve the RNC/BSC IP address from the UE upon the initial request at the RTSP/HTTP Session establishment phase. Thereafter, the UE continuously is updated with regard to the RNCBSC's IP Address/Port number, for which it has established a PDP context Additionally, in case of inter-RNC/BSC handover, the mobility management procedures ensure that the "new" RNC/BSC gets updated so that the RC service continues without any interruption.
  • the Proxy signals specific RC parameters (RC ID, RC IP address (of the proxy), RC port number, UE IP address and UE data destination port number) to the RNC.
  • the RNC binds the RC ID with the RAB for the session to know where to send the RC messages.
  • the RNC "sniffs" for every RAB the user data flow thereby extracting the UE IP address and UE data destination port number. This information may be used to bind the RC ID with the proper RAB.
  • Fig. 12 illustrates an example of a person-to-person (P2P) bit rate adaptation in an UMTS-system in accordance with one aspect of the present invention.
  • the UMTS-system shown in Fig. 12 comprises two core networks, CN 350a, and CN 350b.
  • the core network CN 350a comprises a Gateway GPRS Support Node (GGSN) 352a connected to a Serving GPRS Support Node (SGSN) 354a.
  • the GGSN 352a may be connected to a plurality of SGSNs.
  • the GGSN 352a is a gateway towards external networks such as PSTNs or other mobile networks and the SGSN 354a is connected to at least one Radio Controlling Entity (RCE) (not shown in Fig. 12 ).
  • RCE Radio Controlling Entity
  • Each RCE comprises a Radio Network Controller (RNC) 356a and at least one base station (not shown in Fig. 12 ) connected to a respective RNC 356a in the UMTS network
  • RNC Radio Network Controller
  • Each base station provides wireless communication with a mobile terminal UE 358a.
  • the core network CN 350b comprises a Gateway GPRS Support Node (GGSN) 352b connected to a Serving GPRS Support Node (SGSN) 354b.
  • the GGSN 352b may be connected to a plurality of SGSNs.
  • the SGSN 354b is connected to at least one Radio Controlling Entity (RCE) (not shown in Fig. 12 ).
  • RCE Radio Controlling Entity
  • Each RCE comprises a Radio Network Controller (RNC) 356b and at least one base station (not shown in Fig. 12 ) connected to the RNC in the UMTS network.
  • Each base station provides wireless communication with a mobile terminals UE 358b.
  • At least one of the RCEs comprises a rate controlling means for controlling the bit rate of its radio link Uu.
  • the rate controlling means is preferably a part of a Radio Resource Management (RRM) system.
  • the rate controlling means includes a negotiating means. The negotiating means is arranged to perform a negotiation of radio link layer bit rates between two rate controlling means.
  • rate control messages may also be sent between two UEs or between two RNCs through an intermediate node or proxy 360 in a service network 366.
  • rate control messages may be sent to an "equivalent" node in a fixed network, such as a Media Gateway 362, which may be in communication with a fixed phone 364.
  • a first rate controlling means of the radio link transmits modification information to a second rate controlling means of a second radio link 366b.
  • a proposed application layer bit rate modification is then negotiated between the second and the first rate controlling means by the negotiating means.
  • the negotiating means may be arranged to communicate the outcome of the negotiation to at least one of the rate controlling means.
  • the respective mobile terminals UE 358a, UE 358b are requested from the respective rate controlling means to adapt their sending application layer bit rates, and/or receiving application layer bit rates, accordingly.
  • the respective rate controlling means transmits a radio message to their connected terminals by using a radio communication protocol, e.g. the Radio Resource Control (RRC) protocol to request the mobile terminals to adapt to the new application layer bit rate.
  • RRC Radio Resource Control
  • the radio message is mapped to the application layer in order to perform the negotiated change of the application layer bit rate.
  • the rate controlling means may reside in a number of entities.
  • the first rate controlling means may reside in the first RCE, while the second rate controlling means may reside in the same RCE.
  • each RCE could have its own rate controlling means, or the controlling means could be within another network, such as a fixed network. If the first and second rate controlling means are located within the same RCE, the communication and negotiation between the two rate controlling means are fast and straightforward. If the first and second rate controlling means communicate via intermediate nodes and/or gateways, such as GPRS support nodes, then the RNC sends rate control messages to other nodes within the system.
  • the first RNC 356a might use an IP address of a second mobile terminal UE 358b to send a rate control message to the second RNC 356b.
  • This IP address may be used by intermediate nodes, e.g. the GGSN 352a to route the message to the second RNC 356b, which will interpret, and act upon it.
  • the RNC does not initially know the IP address of the second mobile terminal.
  • the RNC may be configured or "set up" to send RC messages to another RNC, the proxy or another node such as the media gateway.362.
  • the following discussion provides examples illustrating set up procedures for an RNC in various situations.
  • Fig. 13 illustrates an example where the UE configures the RNC with the needed parameters for the rate control service.
  • the RNCs have no IP addresses of their own.
  • the UE 358a starts by sending a SIP INVITE message to UE 358b.
  • This message contains an SDP file, which describes the UE 358a characteristics.
  • the file includes RC parameters (ID, IP address and Port number) and an attribute indicating that UE 358A supports RC service.
  • This attribute may be utilized by UE 358B in order to indicate to ROC-8 that UE 358A is attached to the RAN supporting the rate control service.
  • UE 358B replies with a message containing its session description with the same information.
  • the UE 358A PDP context request message contains the RC parameters of UE 358B. This information is forwarded to the RNC 356A by the SGSN 354A by means of RANAP RAB Assignment Request message.
  • the UE defines or "sets up" the TFT packet filters of secondary PDP context in such a way that it includes RC messages (e.g., the incoming RC messages will be mapped onto this secondary PDP context).
  • TFT is used by the GGSN to map the incoming packets onto the right PDP context.
  • TFT consists of one or several packet filters each containing, among other information: source address, destination port range, and a source port range. TFT is created by the UE and delivered to the GGSN in the ⁇ Activate PDP Context Request" message.
  • the UE collects the information about the session data flow such as IP addresses and port numbers, and in particular among others RC parameters. It enables the UE to define the TFT that will be used by the GGSN to map the incoming data and rate control packets onto this particular PDP context In this manner the incoming RC messages may be mapped onto the PDP context which carries data to control and the RNC will be able to intercept the message and to bind it with the RAB to be controlled.
  • the information about the session data flow such as IP addresses and port numbers, and in particular among others RC parameters. It enables the UE to define the TFT that will be used by the GGSN to map the incoming data and rate control packets onto this particular PDP context In this manner the incoming RC messages may be mapped onto the PDP context which carries data to control and the RNC will be able to intercept the message and to bind it with the RAB to be controlled.
  • RNC 356A When RNC 356A receives the RANAP message, containing the RC parameters, it understands that the available transfer bit rates must be communicated to a remote entity.
  • the RNC 356A uses the RC IP address (IP address of UE 358B) to route the GTP-U or lu UP Initialization message towards UE 358B.
  • the message contains the DL bit rates available over air interface A.
  • the RNC-B uses "sniffing" technique to intercept the message as all traffic to UE 338B will pass through RNGB.
  • sniffing means that the RNGB listens to the user data traffic from UE 358A to UE 358B and intercepts messages that are marked, e.g., an RC ID field in the GTP-U protocol or destination port number in IP header, to facilitate the RC service.
  • Such sniffing techniques are discussed above in reference to Figs. 7 and 8 .
  • the RNC-B is able to bind the RC message with correct RAB because the RC message has arrived from that particular RAB.
  • Fig. 14 illustrates an example where one of the UEs configures the appropriate RNC with the needed parameters for the rate control service.
  • the RNCs have their own IP addresses/port numbers.
  • the UEs are updated continuously with regard to the RNC/BSC's IP Address/Port number, four which they establish a PDP context.
  • the procedure 410 of Fig. 14 is similar to procedure 370 of Fig. 13 in that the RC ID is used to bind the application session with the RAB.
  • the RC IP address and RC Port number correspond to the respective RNC's IP address and Port number.
  • the RNCs are "set-up" with the RC ID, the IP address, and Port number of the corresponding RNCs. Thereafter, the RNC 356a may indicate to RNC 356b that it has either a shortage or spare radio resources by sending a Rate Control (RC) message to RNC 356B or vice versa .
  • the message contains RC ID and bit rate value.
  • the RNC 356B binds the RC message with a proper RAB basing on RC ID. The same mechanism may also be used in the reverse direction (i.e. from the RNC 356b to the RNC 356a).
  • the mobility management procedures update any new and corresponding RNCs with necessary data (e.g. new/updated RNC IP addresses/Port numbers) to continue the Rate Control service without any interruption.
  • Fig. 15 illustrates an example where the proxy sets up the RNC or BSC.
  • the RNC is not associated with any IP address and UE is unaware of the RC service.
  • the RNC and the proxy are pre-configured by means of configuration tool with RC port number. This RC port number is used by the proxy as source port number for the RC messages.
  • the RNC uses the RC port number to single out RC messages, in other words, the messages that have source port number equal to the RC port number. In this scenario the proxy initializes the RNCs.
  • UE 358A initiates the application session by sending an INVITE message to UE 358B, via the SIP-Proxy.
  • the message includes a SDP file, which specifies the rates that are applicable for the session.
  • the UEs After the initial SIP signalling, the UEs establish the secondary PDP contexts TFT packet filters in such a way that they include the user data flow, as the UEs are unaware of the RC service [see 3GPP TS 23.060].
  • the proxy is a SIP proxy it intercepts the SIP messages and thereby can read and store all the information about the UEs and session. Afterwards the proxy initialises the RNCs.
  • the Proxy 360 sends an Initialization message to UE 358A and UE 358B IP destination addresses and user data port numbers as destination port, the source port is the RC port number (pre-configured) and source IP address is Proxy IP address.
  • the message contains following parameters:
  • the GGSN maps the incoming initialisation message to the PDP context carrying the user data flow (i.e. the PDP context carrying the data to be controlled) since the IP address and destination port number of the RC message equals the ones of the user data.
  • the RNCs "sniff" all the incoming traffic of that particular user and intercept the packets that have the RC port as source port, i.e. RC messages. RNCs are able to bind the RC message with correct RAB because the RC message has arrived from that particular RAB.
  • RNC 356A sends the RC Initialisation message to the RC IP address and RC port number (i.e. to the UE 358B).
  • the message contains initial bit rate and RC ID.
  • GGSN-B maps the incoming initialisation message to the correct PDP context since the IP address and destination port number of RC message equals the user data flow.
  • RNC 356B upon "sniffing" all the incoming traffic of that particular user, intercepts the packets that have the RC port as source port, i.e. RC messages. RNC is able to bind the RC message with correct RAB because the RC message has arrived from that particular RAB.
  • RNC 356B then replies to the Initialisation RC message in a similar manner to previous examples discussed above.
  • Fig. 16 illustrates a procedure 480 where a proxy sets up the RNC or BSC.
  • the procedure 480 is similar to the procedure 440 discussed in reference to Fig. 15 .
  • the RNCs have IP addresses and the local SIP proxy has knowledge of the addresses.
  • the Proxy continuously gets updated with regard to the RNC/BSC's IP Address/Port number, for which UEs have established a PDP context.
  • the RNC address could alternatively be received from the UE.
  • the UE 358A initiates the application session by sending an INVITE message to UE 358B, via SIP-Proxies (one or several such proxies).
  • SIP-Proxies one or several such proxies.
  • the first SIP-Proxy adds the RNC-IP address and Port number to the SIP message.
  • the SDP file specifies the rates that are applicable for the session. Alternatively, if it is the UE that knows of the RNC IP address, then the UE may add this information to the SIP message.
  • UE 358A and UE 3588 know each other's application session characteristics, they start the PDP context activation procedure. Thereafter, UE 358A sends a SIP acknowledgement to UE 358B, via the SIP-Proxies.
  • the SIP-Proxies intercept this message and issue the Rate Control service by sending RC Request messages to its local RNC. These messages contain specific RC parameters (RC ID, RC IP address, RC port number, UE IP address and UE data destination port number).
  • the appropriate RNC binds the RC ID with the RAB so that the session will know where to send the Rate Control messages.
  • the RNC "sniffs" for every RAB in the user data flow thereby extracting the UE IP address and UE data destination port number. This information is used to bind the RC ID with the proper RAB.
  • some embodiments of the present invention may communicate with a media gateway.
  • the media gateway may also set up the RNC/BSC for RC service, which can be used, for instance, in mobile-to-fixed phone communication.
  • RC service can be used, for instance, in mobile-to-fixed phone communication.
  • This P2P situation may be similar to a P2C case where the Proxy is replaced by the Media Gateway (MGW).
  • MGW performs transcoding functionality between PLMN and PSTN.
  • the RC service may be used to properly set the transcoder's bit rate.
  • Fig. 17 is such an example where the UE sets up the RNC (or alternatively, the BSC) with the necessary parameters for Rate Control service upon PDP context establishment.
  • the MGW adds the specific RC parameters to the SIP/SDP protocol.
  • the RRC may or may not have an IP address of its own.
  • a specific identity has been added in order to implement the RC Rate Control service.
  • the RC ID i.e., the RC ID
  • the RC IP address and RC Port number correspond to the MGWs IP address and Port number.
  • the RC set-up in this example is conceptually similar to the procedure 210 described in reference to Fig. 9 .
  • SIP protocol is used to set up the session rather than RTSP.
  • the RC parameters therefore, are sent to the UE in the SIP OK message.
  • Fig. 18 is an example where the MGW sets up the RNC or the BSC with the required parameters for the rate control service upon PDP context establishment.
  • the RNC is not associated with an IP address and the UE is unaware of the RC service.
  • the RNC and the MGW may be pre-configured by means of a configuration tool with RC port number. This RC port number is used by the MGW as a source port number for all RC messages.
  • the RNC uses the RC port number to single out RC messages, i.e. the messages that have source port number equal to the RC port number.
  • the UE After SIP initial signalling, the UE establishes the secondary PDP context where TFT packet filters in such a way that it includes only the user data flow, as the UE is unaware of the RC service [see 3GPP TS 23.060]. Because the UE is unaware of the RC service, it can only define TFT packet filters of the secondary PDP context for user data packets (in other words, it cannot include RC messages). So the RC messages are mapped onto the same PDP context as the user data. Therefore from the perspective of the GGSN, the RC messages appear to be the user data. This mapping may be achieved assigning to the RC messages the same IP parameters as the data packet, but the source port number is the RC port.
  • the incoming RC message will be mapped by GGSN onto data PDP context.
  • the RC messages then may be intercepted by the RNC which uses the RC source port number as an identifier.
  • the RNC is preconfigured by means of a configuration tool so it will recognize this type of message.
  • the MGW In order to preconfigure or "initialize" the RNC, the MGW sends an initialization message whose IP/UDP header contains: UE IP address and user data port number as destination address and port, the source port is the RC port number (pre-configured to be the port at which the MGW will listen to the RC messages) and source IP address is the MGW's IP address (i.e., the RC IP address).
  • the message may also contain the RC ID.
  • the applicable GGSN maps the incoming initialization message to the PDP context carrying the user data flow (i.e. the PDP context carrying the data to be controlled) since the IP address and destination port number of the RC message equal the ones of the user data.
  • the RNC "sniffs" all the incoming traffic for that particular user and intercepts the packets that have the RC port as source port, i.e. RC messages.
  • the RNC is able to bind the RC message with correct Radio Access Bearer (RAB) because the RC message has arrived from that particular RAB.
  • RAB Radio Access Bearer
  • the RNC sends the RC Response message to the RC IP address and RC port number (i.e. to the MGW).
  • the message contains initial bit rate and RC ID.
  • Fig. 19 is an example where the MGW sets up the RNC/BSC with the required parameters for the rate control service upon PDP context establishment.
  • the RNC has an IP address and this address is known to the MGW.
  • the MGW may, for example, retrieve the RNC/BSC IP address from the UE upon RTSP/HTTP session establishment phase, or alternatively, upon a SIP establishment phase. (The UE is continuously updated with regard to the RNC IP Address/Port number, for which it has established a PDP context).
  • Embodiments of the invention could also incorporate a system incorporating a method for controlling the transmission flow rate of data bits in a data bit transfer session from a serving entity to a client, the session involving bit transfer over a wireless communications link, the system comprising: a means for setting up the session by providing a radio control node to establish flow rate parameters relating to the wireless link, wherein the setting up includes: a means for resolving addressing between the radio control node and the serving entity, a means for sending rate control configuration parameters to the radio control node, a means for generating in the radio control node an initial rate control (RC) message including initial flow rate parameters, a means for sending at least one initial rate control message to allow the serving entity to set
  • RC initial rate control
  • Such a system may further comprise a means for examining, by the radio control node, every message header in the flow between the client and the serving entity to obtain rate control configuration parameters within the examined messages.
  • the system may also comprise a means for activating an intermediate layer information set between the client and a gateway node; a means for sending, by the gateway node, an application layer message to the serving entity, including the IP address of the client; a means for receiving, by the radio control node, a radio control initiation message from the serving entity, including the IP address of the serving entity to allow the radio control node to send messages to the serving entity; and a means for sending, by the radio control node, a rate control message to the serving entity, wherein the rate control message contains flow rate parameters.
  • the system may also comprise a means for initiating a session, by the client, by sending an application layer command to the serving entity, a means for sending, by the serving entity, a transport layer command to the client, a means for examining, by the radio control node, headers of transport layer commands from the serving entity to obtain rate control configuration parameters within the transport layer command, a means for sending, by the radio control node, a rate control feed back in response to finding rate control configuration parameters in the transport layer command.
  • the means for setting up further may also comprise: a means for initiating the session according to an application level protocol, a means for receiving, by the radio control node, the rate control configuration parameters according to a first intermediate layer protocol; a means for tying the first intermediate layer control configuration parameters to parameters according to a second intermediate layer protocol; a means for generating the tied parameters; and a means for including the tied parameters in the initial rate control message.
  • the means for setting up may further comprise: a means for initiating the session according to an application level protocol, a means for receiving, by the radio control node, the rate control configuration parameters according to an intermediate layer protocol; a means for sending the initial rate to the rate control IP address specified in the configuration parameters.
  • the system may also comprise a means for activating an intermediate layer information set between the client and a serving support node in the network.
  • the serving entity of the system may be an application server, a streaming server or a proxy in communication with an application server.
  • the client may be a mobile station.
  • the rate control configuration parameters may be selected from the group consisting of a rate control method indicator, a rate control identifier, a rate control IP address, and rate control port numbers.
  • the flow rate parameters are selected from the group consisting of a rate control identifier and a bit rate.
  • the application layer protocol may be the Real Time Streaming Protocol (RTSP), the first intermediate protocol is Radio Access Network Application Part (RANAP), and the second intermediate protocol is lu UP or GTP over IP.
  • RTSP Real Time Streaming Protocol
  • RANAP Radio Access Network Application Part
  • the session may occur within a network which is a Universal Mobile Telephony System (UMTS), a General Packet Radio Service (GPRS) system, or a WLAN network.
  • UMTS Universal Mobile Telephony System
  • GPRS General Packet Radio Service
  • the resolving may also include: initiating a session by sending set up commands in accordance with an application layer protocol between the first mobile entity and the second mobile entity, establishing an intermediate layer information set between the first mobile entity and a serving node, receiving, by the first radio control node, rate control configuration parameters for the second mobile entity according to a first intermediate layer protocol; and receiving, by the second radio control node, rate control configuration parameters for the first mobile entity according to a first intermediate layer protocol.
  • the system may contain instructions for examining, by the first radio control node, the headers of messages addressed to the first mobile entity to obtain the available transmission rates for the second radio link, and examining, by the second radio control node, the headers of message addressed to the second mobile entity to obtain the available transmission rates for the first radio link.
  • the system may contain instructions for providing a proxy whereby all messages intended to received by the first mobile entity from the second mobile entity, all messages received by the second mobile entity from the first mobile entity, are sent through and forwarded on by the proxy, or examining, by the first radio control node, the headers of messages addressed to the first mobile entity to obtain rate control configuration parameters relating to the second mobile entity, and examining, by the second radio control node, the headers of message addressed to the second mobile entity to obtain rate control configuration parameters relating to the first mobile entity.
  • the system may contain instructions for providing a first proxy whereby all messages sent by the first mobile entity to the second mobile entity, all messages sent by the first radio control node to the second radio control node, are sent to and forwarded on by the first proxy. Additionally, some embodiments may comprise instructions for providing a second proxy whereby all messages sent by the second mobile entity to the first mobile entity, and all messages sent by the second radio control node to the first radio control node are sent to and forwarded on by the second proxy.
  • the application layer protocol used by the system is a Session initiation Protocol
  • the first intermediate layer protocol is Radio Access Network Application Part (RANAP)
  • RANAP Radio Access Network Application Part
  • the second intermediate layer protocol is lu UP.
  • a system for controlling the transcoding rate of a media gateway during a data bit transfer session from the media gateway to a client, the bit transfer session involving bit transfer over a wireless communications link comprising: a means for setting up the session by providing a radio control node to establish transcoding rate parameters relating to the wireless link, wherein the setting up includes: a means for resolving addressing between the radio control node and the media gateway, a means for sending rate control configuration parameters to the radio control node, a means for generating in the radio control node an initial rate control message including initial transcoding rate parameters, a means for sending at least one initial rate control message so that the media gateway can set initial transcoding rates for the session in accordance with at least one of the initial transcoding rate parameters; a means for monitoring the wireless communication link; a means for based on monitoring, sending new transcoding rate parameters so that the media gateway can update the transmission rate of the session in accordance with the new transcoding rate parameters.
  • inventions may contain a means for examining, by the radio control node, every message header in the flow between the client and the media gateway to obtain rate control configuration parameters within the examined messages.
  • embodiments may included a means for activating an intermediate layer information set between the client and a gateway node in the network; a means for sending, by the gateway node, an application layer message to the media gateway, including the IP address of the client; and a means for receiving, by the radio control node, a rate control initiation message, including the IP address of the media gateway to allow the radio control node to send messages to the media gateway.
  • Other embodiments may included a means for initiating a session, by the client, by sending an application layer command to the media gateway, a means for sending, by the media gateway, a transport layer command to the client wherein the transport layer command includes rate control configuration parameters; and a means for examining, by the radio control node, the headers of transport layer commands to obtain rate control configuration parameters within the transport layer commands.
  • the means for setting up further includes a means for initiating the session according to an application level protocol, a means for receiving, by the radio control node, the rate control configuration parameters according to a first intermediate layer protocol; a means for tying the first intermediate layer control configuration parameters to parameters according to a second intermediate layer protocol; a means for generating the tied parameters; and a means for including the tied parameters in the initial rate control message.
  • the means for setting up further includes a means for initiating the session according to an application level protocol, a means for receiving, by the radio control node, the rate control configuration parameters according to an intermediate layer protocol; a means for sending the initial rate to the rate control IP address specified in the configuration parameters.
  • Such embodiments may further comprise a means for activating an intermediate layer information set between the client and a serving support node in the network, wherein the client may be a mobile station.
  • the rate control configuration parameters may be selected from the group consisting of a rate control method indicator, a rate control identifier, a rate control IP address, and rate control port numbers
  • the transcoding rate parameters may be selected from the group consisting of a rate control identifier and a bit rate.
  • the application layer protocol may be the SIP [Session Initiated Protocol]
  • the first intermediate protocol may be Radio Access Network Application Part (RANAP)
  • the second intermediate protocol may be lu UP.
  • the session may occur within a network which is a Universal Mobile Telephony System (UMTS), a General Packet Radio Service (GPRS) system, or a WLAN network.
  • UMTS Universal Mobile Telephony System
  • GPRS General Packet Radio Service

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)
  • Selective Calling Equipment (AREA)
  • Circuits Of Receivers In General (AREA)

Claims (8)

  1. Procédé de négociation du débit d'émission de bits de données dans une session de transfert de bits de données entre une première entité mobile (358a) et une seconde entité mobile, la session comprenant l'émission de bits sur au moins une liaison de communication sans fil (366a, 366b), le procédé étant caractérisé par les étapes consistant à :
    fournir un premier noeud de commande radio (356a) en communication avec la première entité mobile (358a), afin de commander les débits d'émission de bits d'une première liaison radio (366a) vers la première entité mobile ;
    fournir un second noeud de commande radio (356b) en communication avec la seconde entité mobile, afin de commander les débits d'émission de bits d'une seconde liaison radio (366b) vers la seconde entité mobile ;
    résoudre l'adressage entre le premier noeud de commande radio (356a) et le second noeud de commande radio (356b) afin de permettre la communication entre le premier noeud de commande radio (356a) et le second noeud de commande radio ;
    envoyer des paramètres de commande du débit pour la première liaison au second noeud de commande radio ;
    envoyer des paramètres de commande du débit pour la seconde liaison au premier noeud de commande radio ;
    faire correspondre les paramètres de commande du débit pour obtenir un débit réel d'émission de bits ;
    envoyer un indicateur du débit réel d'émission de bits à la première entité mobile (358a) et à la seconde entité mobile (358b), afin que l'émission de bits puisse se produire avec le débit d'émission de bits.
  2. Procédé selon la revendication 1, dans lequel l'étape de résolution comprenant en outre les étapes consistant à :
    lancer une session en envoyant des instructions d'établissement en fonction d'un protocole de la couche applicative, entre la première entité mobile (358a) (UE-A 358a) et la seconde entité mobile (358b) (UE-B 358b) ;
    établir un ensemble d'informations de couche intermédiaire entre la première entité mobile (358a) (UE-A 358a) et un noeud de desserte ;
    recevoir par le premier noeud de commande radio des paramètres de configuration de commande du débit pour la seconde entité mobile (358b), en fonction d'un premier protocole de couche intermédiaire ; et
    recevoir par le second noeud de commande radio des paramètres de configuration de commande du débit pour la première entité mobile (358a), en fonction d'un premier protocole de couche intermédiaire.
  3. Procédé selon la revendication 2, comprenant en outre les étapes consistant à :
    examiner par le premier noeud de commande radio les entêtes des messages adressés à la première entité mobile (358a) afin d'obtenir les débits d'émission disponibles pour la seconde liaison radio ; et
    examiner par le second noeud de commande radio les entêtes des messages adressés à la seconde entité mobile (358b) afin d'obtenir les débits d'émission disponibles pour la première liaison radio (366a).
  4. Procédé selon la revendication 1, comprenant en outre l'étape consistant à :
    fournir un serveur mandataire, afin que tous les messages destinés à être reçus par la première entité mobile (358a) en provenance de la seconde entité mobile et tous les messages reçus par la seconde entité mobile (358b) en provenance de la première entité mobile soit envoyés via le serveur mandataire et ré-acheminés par celui-ci.
  5. Procédé selon la revendication 4, comprenant en outre les étapes consistant à :
    examiner par le premier noeud de commande radio les entêtes des messages adressés à la première entité mobile (358a) afin d'obtenir les débits d'émission disponibles pour la seconde entité mobile ; et
    examiner par le second noeud de commande radio les entêtes des messages adressés à la seconde entité mobile (358b) afin d'obtenir les débits d'émission disponibles pour la première entité mobile.
  6. Procédé selon la revendication 1, comprenant en outre l'étape consistant à fournir un premier serveur mandataire, afin que tous les messages envoyés par la première entité mobile (358a) à la seconde entité mobile et tous les messages envoyés par le premier noeud de commande radio (356a) au second noeud de commande radio soit envoyés via le premier serveur mandataire et ré-acheminés par celui-ci.
  7. Procédé selon la revendication 6, comprenant en outre l'étape consistant à fournir un second serveur mandataire, afin que tous les messages envoyés par la seconde entité mobile (358b) (UE-B 358b) à la première entité mobile (358a) (UE-A 358a) et tous les messages envoyés par le second noeud de commande radio (356b) au premier noeud de commande radio (356a) soit envoyés via le second serveur mandataire et ré-acheminés par celui-ci.
  8. Procédé selon les revendications 1 à 7, dans lequel le protocole de la couche applicative est un protocole de lancement de session (SIP pour « Session Initiation Protocol »), le premier protocole de couche intermédiaire est la partie applicative du réseau d'accès radio (RANAP, pour « Radio Access Network Application Part ») et le second protocole de couche intermédiaire est le protocole Iu UP.
EP09007414A 2003-04-07 2003-11-18 Methode et systeme de negotiation de debit dans un réseau Expired - Lifetime EP2099179B1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SE0301053A SE0301053D0 (sv) 2003-04-07 2003-04-07 Method and system in a communications network
EP03816585A EP1614258B1 (fr) 2003-04-07 2003-11-18 Procede et systeme de commande du debit dans un reseau

Related Parent Applications (2)

Application Number Title Priority Date Filing Date
EP03816585A Division EP1614258B1 (fr) 2003-04-07 2003-11-18 Procede et systeme de commande du debit dans un reseau
EP03816585.8 Division 2003-11-18

Publications (2)

Publication Number Publication Date
EP2099179A1 EP2099179A1 (fr) 2009-09-09
EP2099179B1 true EP2099179B1 (fr) 2010-10-06

Family

ID=20290981

Family Applications (2)

Application Number Title Priority Date Filing Date
EP09007414A Expired - Lifetime EP2099179B1 (fr) 2003-04-07 2003-11-18 Methode et systeme de negotiation de debit dans un réseau
EP03816585A Expired - Lifetime EP1614258B1 (fr) 2003-04-07 2003-11-18 Procede et systeme de commande du debit dans un reseau

Family Applications After (1)

Application Number Title Priority Date Filing Date
EP03816585A Expired - Lifetime EP1614258B1 (fr) 2003-04-07 2003-11-18 Procede et systeme de commande du debit dans un reseau

Country Status (9)

Country Link
US (1) US20070025301A1 (fr)
EP (2) EP2099179B1 (fr)
CN (2) CN1774890B (fr)
AT (1) ATE484134T1 (fr)
AU (1) AU2003276592A1 (fr)
DE (1) DE60334508D1 (fr)
ES (1) ES2390582T3 (fr)
SE (1) SE0301053D0 (fr)
WO (1) WO2004091151A1 (fr)

Families Citing this family (168)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE602004005146T2 (de) * 2004-01-06 2007-11-15 Alcatel Lucent Session-Ressource-Broker für physikalische Schicht
US20050243746A1 (en) * 2004-04-29 2005-11-03 Nokia Corporation Session inspection scheme
US7984149B1 (en) * 2004-08-04 2011-07-19 Cisco Technology, Inc. Method and apparatus for identifying a policy server
US7672272B2 (en) * 2004-08-31 2010-03-02 Telefonaktiebolaget L M Ericsson (Publ) Frame size adaptation in real-time transport protocol
US20060114855A1 (en) * 2004-11-30 2006-06-01 Haihong Zheng Quality of service (QOS) signaling for a wireless network
KR100666956B1 (ko) * 2005-03-08 2007-01-10 삼성전자주식회사 네트워크에서의 미디어 전송 장치 및 방법
US7818001B2 (en) * 2005-03-25 2010-10-19 Alcatel-Lucent Usa Inc. Fine grain downlink active set control
US8719399B2 (en) 2005-04-07 2014-05-06 Opanga Networks, Inc. Adaptive file delivery with link profiling system and method
US11258531B2 (en) 2005-04-07 2022-02-22 Opanga Networks, Inc. System and method for peak flow detection in a communication network
US9065595B2 (en) * 2005-04-07 2015-06-23 Opanga Networks, Inc. System and method for peak flow detection in a communication network
US7500010B2 (en) * 2005-04-07 2009-03-03 Jeffrey Paul Harrang Adaptive file delivery system and method
US8589508B2 (en) * 2005-04-07 2013-11-19 Opanga Networks, Inc. System and method for flow control in an adaptive file delivery system
US8909807B2 (en) * 2005-04-07 2014-12-09 Opanga Networks, Inc. System and method for progressive download using surplus network capacity
FI20050412A0 (fi) * 2005-04-21 2005-04-21 Nokia Corp Menetelmä yhteyksien muodostamiseksi tietoliikennejärjestelmässä
US7656835B2 (en) * 2005-05-18 2010-02-02 Nokia Corporation Method for informing changed communications capabilities
US20060285534A1 (en) * 2005-06-20 2006-12-21 Lucent Technologies Inc. Methods and systems for improved charging information accuracy in a wireless communication system
US7869395B2 (en) 2005-09-30 2011-01-11 Research In Motion Limited Methods and apparatus for dynamically adjusting a data packet window size for data packet transmission in a wireless communication network
US9219686B2 (en) * 2006-03-31 2015-12-22 Alcatel Lucent Network load balancing and overload control
KR100966047B1 (ko) * 2006-08-25 2010-06-28 삼성전자주식회사 통신시스템에서 미디어 송신 방법 및 장치
US20080069101A1 (en) * 2006-09-15 2008-03-20 Nokia Corporation System and method of routing packets
CN101155260A (zh) * 2006-09-30 2008-04-02 华为技术有限公司 电子设备的控制方法、鉴权方法和服务器
WO2008049462A1 (fr) * 2006-10-26 2008-05-02 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et récepteur pour contrôler la conformité d'un flux de données dans un système de communication à une définition de trafic
US7907523B2 (en) * 2006-12-05 2011-03-15 Electronics And Telecommunications Research Institute Method and apparatus for controlling variable bit-rate voice codec
US8929360B2 (en) * 2006-12-07 2015-01-06 Cisco Technology, Inc. Systems, methods, media, and means for hiding network topology
EP2103052B1 (fr) 2006-12-28 2012-08-22 Research In Motion Limited Procédés et dispositif pour augmenter le débit de données en regroupant des paquets de données en des unités transmissibles maximales
US20080165679A1 (en) * 2007-01-10 2008-07-10 Ipwireless, Inc. Method to mitigate fraudulent usage of QoS from mobile terminals using uplink packet marking
EP2109940A4 (fr) * 2007-01-16 2013-10-09 Opanga Networks Inc Système et procédé de gestion d'acheminement de données sans fil
US8081609B2 (en) * 2007-02-14 2011-12-20 Alcatel Lucent Proxy-based signaling architecture for streaming media services in a wireless communication system
US7706266B2 (en) * 2007-03-12 2010-04-27 Citrix Systems, Inc. Systems and methods of providing proxy-based quality of service
CN101690330B (zh) * 2007-06-22 2014-05-28 交互数字技术公司 用于切换操作中的资源管理的方法和设备
CN101364883B (zh) * 2007-08-06 2011-12-28 华为技术有限公司 一种多终端会话方法及通讯系统以及相关设备
US8812712B2 (en) 2007-08-24 2014-08-19 Alcatel Lucent Proxy-driven content rate selection for streaming media servers
CN101431394B (zh) * 2007-11-05 2012-01-11 中兴通讯股份有限公司 下行隧道混合自动重传请求方法
US20110007737A1 (en) * 2007-11-06 2011-01-13 Alain Bultinck Delivery of media streaming services in a mobile communication system
EP2213119B1 (fr) * 2007-11-16 2014-01-08 Nokia Solutions and Networks Oy Mappage de qualité de service pour transfert intersystème
EP2091203A1 (fr) * 2008-02-12 2009-08-19 Koninklijke KPN N.V. Procédé et système pour transmettre un flux multimédia
JP5093526B2 (ja) * 2008-01-16 2012-12-12 日本電気株式会社 ゲートウェイ装置およびシステム、並びに、通信方法
EP2248300B1 (fr) * 2008-02-25 2013-06-12 Telefonaktiebolaget L M Ericsson (PUBL) Remise de données à multidiffusion
CN101978667B (zh) * 2008-03-20 2014-12-31 诺基亚通信公司 通信网络系统中的不同ip接口
US8949719B2 (en) * 2008-05-23 2015-02-03 Viasat, Inc. Methods and systems for user interface event snooping and prefetching
US8340634B2 (en) 2009-01-28 2012-12-25 Headwater Partners I, Llc Enhanced roaming services and converged carrier networks with device assisted services and a proxy
US8635335B2 (en) 2009-01-28 2014-01-21 Headwater Partners I Llc System and method for wireless network offloading
US9083521B2 (en) * 2008-06-05 2015-07-14 Qualcomm Incorporated System and method of an in-band modem for data communications over digital wireless communication networks
US8402111B2 (en) 2009-01-28 2013-03-19 Headwater Partners I, Llc Device assisted services install
US8548428B2 (en) 2009-01-28 2013-10-01 Headwater Partners I Llc Device group partitions and settlement platform
US8725123B2 (en) 2008-06-05 2014-05-13 Headwater Partners I Llc Communications device with secure data path processing agents
US8898293B2 (en) 2009-01-28 2014-11-25 Headwater Partners I Llc Service offer set publishing to device agent with on-device service selection
US8825480B2 (en) * 2008-06-05 2014-09-02 Qualcomm Incorporated Apparatus and method of obtaining non-speech data embedded in vocoder packet
US8832777B2 (en) 2009-03-02 2014-09-09 Headwater Partners I Llc Adapting network policies based on device service processor configuration
US8406748B2 (en) 2009-01-28 2013-03-26 Headwater Partners I Llc Adaptive ambient services
US8964788B2 (en) * 2008-06-05 2015-02-24 Qualcomm Incorporated System and method of an in-band modem for data communications over digital wireless communication networks
US8391834B2 (en) 2009-01-28 2013-03-05 Headwater Partners I Llc Security techniques for device assisted services
US8346225B2 (en) 2009-01-28 2013-01-01 Headwater Partners I, Llc Quality of service for device assisted services
US8839388B2 (en) 2009-01-28 2014-09-16 Headwater Partners I Llc Automated device provisioning and activation
US8924543B2 (en) 2009-01-28 2014-12-30 Headwater Partners I Llc Service design center for device assisted services
US8275830B2 (en) 2009-01-28 2012-09-25 Headwater Partners I Llc Device assisted CDR creation, aggregation, mediation and billing
US8958441B2 (en) * 2008-06-05 2015-02-17 Qualcomm Incorporated System and method of an in-band modem for data communications over digital wireless communication networks
US8589541B2 (en) 2009-01-28 2013-11-19 Headwater Partners I Llc Device-assisted services for protecting network capacity
US8924469B2 (en) 2008-06-05 2014-12-30 Headwater Partners I Llc Enterprise access control and accounting allocation for access networks
US8503517B2 (en) * 2008-06-05 2013-08-06 Qualcomm Incorporated System and method of an in-band modem for data communications over digital wireless communication networks
US8626115B2 (en) 2009-01-28 2014-01-07 Headwater Partners I Llc Wireless network service interfaces
US8725502B2 (en) * 2008-06-05 2014-05-13 Qualcomm Incorporated System and method of an in-band modem for data communications over digital wireless communication networks
US8516121B1 (en) * 2008-06-30 2013-08-20 Symantec Corporation Method and apparatus for optimizing computer network usage to prevent congestion
US20100027966A1 (en) * 2008-08-04 2010-02-04 Opanga Networks, Llc Systems and methods for video bookmarking
CN101646205B (zh) * 2008-08-05 2014-07-09 华为技术有限公司 移动网络高速接入公网的节点、方法及系统
CN102171664B (zh) 2008-08-06 2014-12-03 莫维克网络公司 无线电接入网(ran)中的内容高速缓存
US8055286B1 (en) * 2008-08-27 2011-11-08 Sprint Spectrum L.P. Modification of en-route message to add destination port number selected based at least in part on message originator
US8116224B2 (en) 2008-09-09 2012-02-14 Embarq Holdings Company, LP System and method for generating alarms based on bursting traffic
KR20110057240A (ko) * 2008-09-18 2011-05-31 오팡가 네트웍스, 인크. 과중 미디어 콘텐트의 자동 검출 및 조정된 배송을 위한 시스템 및 방법
US8488596B2 (en) * 2008-11-03 2013-07-16 At&T Intellectual Property I, L.P. Method and apparatus for sharing a single data channel for multiple signaling flows destined to multiple core networks
WO2010054276A2 (fr) * 2008-11-07 2010-05-14 Jeffrey Harrang Dispositifs de stockage de données portables qui initient des transferts de données à l'aide de dispositifs hôtes
WO2010068497A2 (fr) * 2008-11-25 2010-06-17 Jeffrey Harrang Distribution virale de contenu multimédia numérique via des réseaux sociaux
US8208430B2 (en) * 2008-12-23 2012-06-26 Movik Networks Transparent interaction with multi-layer protocols via selective bridging and proxying
US9578182B2 (en) 2009-01-28 2017-02-21 Headwater Partners I Llc Mobile device and service management
US9755842B2 (en) 2009-01-28 2017-09-05 Headwater Research Llc Managing service user discovery and service launch object placement on a device
US8893009B2 (en) 2009-01-28 2014-11-18 Headwater Partners I Llc End user device that secures an association of application to service policy with an application certificate check
US9609510B2 (en) 2009-01-28 2017-03-28 Headwater Research Llc Automated credential porting for mobile devices
US8793758B2 (en) 2009-01-28 2014-07-29 Headwater Partners I Llc Security, fraud detection, and fraud mitigation in device-assisted services systems
US10200541B2 (en) 2009-01-28 2019-02-05 Headwater Research Llc Wireless end-user device with divided user space/kernel space traffic policy system
US10492102B2 (en) 2009-01-28 2019-11-26 Headwater Research Llc Intermediate networking devices
US8745191B2 (en) 2009-01-28 2014-06-03 Headwater Partners I Llc System and method for providing user notifications
US10057775B2 (en) 2009-01-28 2018-08-21 Headwater Research Llc Virtualized policy and charging system
US10237757B2 (en) 2009-01-28 2019-03-19 Headwater Research Llc System and method for wireless network offloading
US12166596B2 (en) 2009-01-28 2024-12-10 Disney Enterprises, Inc. Device-assisted services for protecting network capacity
US10783581B2 (en) 2009-01-28 2020-09-22 Headwater Research Llc Wireless end-user device providing ambient or sponsored services
US9954975B2 (en) 2009-01-28 2018-04-24 Headwater Research Llc Enhanced curfew and protection associated with a device group
US9253663B2 (en) 2009-01-28 2016-02-02 Headwater Partners I Llc Controlling mobile device communications on a roaming network based on device state
US10798252B2 (en) 2009-01-28 2020-10-06 Headwater Research Llc System and method for providing user notifications
US11985155B2 (en) 2009-01-28 2024-05-14 Headwater Research Llc Communications device with secure data path processing agents
US10326800B2 (en) 2009-01-28 2019-06-18 Headwater Research Llc Wireless network service interfaces
US10248996B2 (en) 2009-01-28 2019-04-02 Headwater Research Llc Method for operating a wireless end-user device mobile payment agent
US9351193B2 (en) 2009-01-28 2016-05-24 Headwater Partners I Llc Intermediate networking devices
US10715342B2 (en) 2009-01-28 2020-07-14 Headwater Research Llc Managing service user discovery and service launch object placement on a device
US10841839B2 (en) 2009-01-28 2020-11-17 Headwater Research Llc Security, fraud detection, and fraud mitigation in device-assisted services systems
US9706061B2 (en) 2009-01-28 2017-07-11 Headwater Partners I Llc Service design center for device assisted services
US9392462B2 (en) 2009-01-28 2016-07-12 Headwater Partners I Llc Mobile end-user device with agent limiting wireless data communication for specified background applications based on a stored policy
US10064055B2 (en) 2009-01-28 2018-08-28 Headwater Research Llc Security, fraud detection, and fraud mitigation in device-assisted services systems
US9572019B2 (en) 2009-01-28 2017-02-14 Headwater Partners LLC Service selection set published to device agent with on-device service selection
US11218854B2 (en) 2009-01-28 2022-01-04 Headwater Research Llc Service plan design, user interfaces, application programming interfaces, and device management
US10264138B2 (en) 2009-01-28 2019-04-16 Headwater Research Llc Mobile device and service management
US11973804B2 (en) 2009-01-28 2024-04-30 Headwater Research Llc Network service plan design
US9270559B2 (en) 2009-01-28 2016-02-23 Headwater Partners I Llc Service policy implementation for an end-user device having a control application or a proxy agent for routing an application traffic flow
US9955332B2 (en) 2009-01-28 2018-04-24 Headwater Research Llc Method for child wireless device activation to subscriber account of a master wireless device
US9858559B2 (en) 2009-01-28 2018-01-02 Headwater Research Llc Network service plan design
US10779177B2 (en) 2009-01-28 2020-09-15 Headwater Research Llc Device group partitions and settlement platform
US9565707B2 (en) 2009-01-28 2017-02-07 Headwater Partners I Llc Wireless end-user device with wireless data attribution to multiple personas
US9980146B2 (en) 2009-01-28 2018-05-22 Headwater Research Llc Communications device with secure data path processing agents
US9647918B2 (en) 2009-01-28 2017-05-09 Headwater Research Llc Mobile device and method attributing media services network usage to requesting application
US9557889B2 (en) 2009-01-28 2017-01-31 Headwater Partners I Llc Service plan design, user interfaces, application programming interfaces, and device management
US10484858B2 (en) 2009-01-28 2019-11-19 Headwater Research Llc Enhanced roaming services and converged carrier networks with device assisted services and a proxy
CN102282550A (zh) * 2009-01-30 2011-12-14 莫维克网络公司 应用和使用以及无线链路感知传输网络调度程序
JP2010178867A (ja) * 2009-02-05 2010-08-19 Fujifilm Corp 放射線撮影用ネットワークシステム及び放射線画像撮影システム制御方法
US8855100B2 (en) * 2009-06-16 2014-10-07 Qualcomm Incorporated System and method for supporting higher-layer protocol messaging in an in-band modem
US8743864B2 (en) * 2009-06-16 2014-06-03 Qualcomm Incorporated System and method for supporting higher-layer protocol messaging in an in-band modem
US8537699B2 (en) 2009-06-16 2013-09-17 Qualcomm Incorporated Managing video adaptation algorithms
US8705361B2 (en) * 2009-06-16 2014-04-22 Tellabs Operations, Inc. Method and apparatus for traffic management in a wireless network
PL2457401T3 (pl) * 2009-07-21 2015-03-31 T Mobile Austria Gmbh Sposób, układ i stacja bazowa zapewniające zwiększoną wydajność komunikacyjną
WO2011022104A1 (fr) * 2009-08-19 2011-02-24 Opanga Networks, Inc. Optimisation de ressources de canal par coordination de transferts de données sur la base d'un type de données et d'un trafic
WO2011022096A1 (fr) * 2009-08-19 2011-02-24 Opanga Networks, Inc Optimisation de la distribution de contenus multimédias basée sur des métriques de ressources déterminées d'un équipement utilisateur
KR101649777B1 (ko) * 2009-08-20 2016-08-19 오팡가 네트웍스, 인크. 잉여 네트워크 용량을 이용한 콘텐츠의 브로드캐스팅
EP2486491A4 (fr) * 2009-10-06 2013-10-23 Unwired Planet Llc Gestion de trafic en réseau par l'édition d'un fichier manifeste et/ou l'utilisation d'un contrôle de débit intermédiaire
US8811416B2 (en) * 2009-11-04 2014-08-19 Nec Corporation Gateway device, mobile terminal, mobile communication method, and program
WO2011057292A1 (fr) 2009-11-09 2011-05-12 Movik Networks, Inc. Planificateur de paquets en rafale pour efficacité ran améliorée dans des réseaux umts/hspa
US8351948B2 (en) * 2010-03-01 2013-01-08 Nec Laboratories America, Inc. Method and system for customizable flow management in a cellular basestation
CN102196513B (zh) * 2010-03-11 2014-02-26 阿尔卡特朗讯 用于确定业务网关接入的业务速率的方法和设备
CN102598628A (zh) * 2010-03-15 2012-07-18 莫维克网络公司 用于多媒体传送的自适应分块和内容感知同步设备及方法
US8495196B2 (en) 2010-03-22 2013-07-23 Opanga Networks, Inc. Systems and methods for aligning media content delivery sessions with historical network usage
US9445215B2 (en) * 2010-04-21 2016-09-13 Telefonaktiebolaget Lm Ericsson (Publ) MTC device bandwidth reduction
US8477618B2 (en) 2010-07-16 2013-07-02 Research In Motion Limited Methods and apparatus for use in communicating data packets within a data packet window having a size that is set based on quality of service (QoS) parameters
EP2408152B1 (fr) * 2010-07-16 2013-11-27 BlackBerry Limited Procédés et appareil pour une utilisation dans des paquets de communications de données dans une fenêtre de paquets de données dont la taille est basée sur des paramètres de qualité de service (QOS)
WO2012012334A2 (fr) 2010-07-19 2012-01-26 Movik Networks Procédés de préanalyse de contenu et d'aide de réseau de distribution de contenu (cdn) dans un réseau mobile sans fil
WO2012040608A2 (fr) * 2010-09-24 2012-03-29 Movik Networks Apprentissage de destination et détection de mobilité dans un dispositif de réseau en transit dans des réseaux d'accès radio lte et umts
JP5745078B2 (ja) * 2010-10-27 2015-07-08 インターデイジタル パテント ホールディングス インコーポレイテッド 発展型アプリケーションインターフェースのためのスケーラブルなポリシー制御パケットインスペクションのシステムおよび方法
EP2448174B1 (fr) * 2010-11-02 2013-05-08 Telefónica Germany GmbH & Co. OHG Appareil de contrôle de trafic de données et procédé de mesure QoE
US9451049B2 (en) 2010-12-13 2016-09-20 Google Technology Holdings LLC Sharing media among remote access clients in a universal plug and play environment
EP2679073A4 (fr) * 2011-02-25 2016-10-19 Ericsson Telefon Ab L M Autorisation de communication ip avec un dispositif de machine à machine
US9154826B2 (en) 2011-04-06 2015-10-06 Headwater Partners Ii Llc Distributing content and service launch objects to mobile devices
US20130051253A1 (en) * 2011-08-23 2013-02-28 James M. Lin Method and apparatus for improving user experience via payload adaptation
US8630307B2 (en) 2011-09-13 2014-01-14 Qualcomm Incorporated Methods and apparatus for traffic contention resource allocation
US10292066B2 (en) * 2011-11-04 2019-05-14 Cisco Technology, Inc. System and method of modifying congestion control based on mobile system information
CN103248451B (zh) * 2012-02-09 2016-12-07 华为技术有限公司 业务速率控制方法和系统以及设备
US8972568B2 (en) * 2012-02-21 2015-03-03 Telefonaktiebolaget L M Ericsson (Publ) Quantifying user quality of experience by passive monitoring
EP2818018B1 (fr) * 2012-02-22 2018-07-11 Telefonaktiebolaget LM Ericsson (publ) Adaptation de la qualité de service sur la base d'une mesure
CN103582029B (zh) * 2012-07-24 2018-05-18 华为技术有限公司 策略控制方法及设备
US9276967B2 (en) 2012-07-27 2016-03-01 Centurylink Intellectual Property Llc System and method for determining optimal bandwidth for streaming to a client device in an adjustable bit rate video system
US9591513B2 (en) * 2012-08-06 2017-03-07 Vid Scale, Inc. Rate adaptation using network signaling
CN103702364B (zh) * 2012-09-27 2017-08-25 华为技术有限公司 一种业务数据传输的方法、设备及系统
US20140281018A1 (en) * 2013-03-13 2014-09-18 Futurewei Technologies, Inc. Dynamic Optimization of TCP Connections
KR102077740B1 (ko) * 2013-03-18 2020-02-14 삼성전자주식회사 기지국과의 통신을 위한 자원을 할당하는 방법 및 단말
US20150112767A1 (en) * 2013-10-17 2015-04-23 Cisco Technology, Inc. System and method for using network mobility events to build advertising demographics
US20160380898A1 (en) 2013-11-27 2016-12-29 Telefonaktiebolaget Lm Ericsson (Publ) Controlling a transmission control protocol window size
US9237467B2 (en) 2013-11-27 2016-01-12 At&T Intellectual Property I, L.P. Adaptive pacing of media content delivery over a wireless network
US10367738B2 (en) * 2014-08-14 2019-07-30 Nokia Solutions And Networks Oy Throughput guidance based on user plane insight
US11695847B2 (en) 2014-08-14 2023-07-04 Nokia Solutions And Networks Oy Throughput guidance based on user plane insight
CN107005530A (zh) * 2014-09-22 2017-08-01 诺基亚通信公司 通信网络系统中的静音呼叫检测
CN104618967B (zh) * 2015-01-30 2018-06-05 上海华为技术有限公司 一种通信方法、相关装置和系统
JP6717008B2 (ja) * 2016-03-31 2020-07-01 富士通株式会社 情報生成プログラム、情報生成方法及び情報生成装置
EP3533162B1 (fr) 2016-10-28 2021-04-07 Telefonaktiebolaget LM Ericsson (PUBL) Gestion du transfert de paquets de données via un mandataire
US10986000B2 (en) * 2017-05-07 2021-04-20 Qualcomm Incorporated Enabling new radio cellular quality of service for non-internet protocol data sessions
WO2019030077A1 (fr) 2017-08-10 2019-02-14 Sony Corporation Procédé de communications sans fil, dispositif de communications, et infrastructure de réseau sans fil
WO2019095295A1 (fr) * 2017-11-17 2019-05-23 Oppo广东移动通信有限公司 Procédé de transmission de données, dispositif terminal et dispositif de fonction de gestion de session (smf)
WO2019166081A1 (fr) * 2018-02-28 2019-09-06 Nokia Technologies Oy Intégration transparente de réseau 3gpp dans un réseau industriel à base de tsn
US11350268B2 (en) * 2018-05-18 2022-05-31 Qualcomm Incorporated End-to-end rate adaptation using RAN assisted rate adaptation
CN116033596A (zh) * 2018-07-18 2023-04-28 北京小米松果电子有限公司 点对点通信方法、装置、存储介质及电子设备
US11228991B2 (en) * 2019-02-01 2022-01-18 Cisco Technology, Inc. Link auto-negotiation between a radio equipment controller (REC) and radio equipment (RE) in an ethernet-based fronthaul network
CN112152934A (zh) * 2019-07-25 2020-12-29 北京天德科技有限公司 显式反馈数据流控制
US11089078B2 (en) * 2019-09-13 2021-08-10 Microsoft Technology Licensing, Llc Model-based parameter selection for media sessions
CN110996298A (zh) * 2019-12-25 2020-04-10 北京汽车集团越野车有限公司 一种通信速率调整系统及汽车

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5115429A (en) * 1990-08-02 1992-05-19 Codex Corporation Dynamic encoding rate control minimizes traffic congestion in a packet network
ZA946674B (en) * 1993-09-08 1995-05-02 Qualcomm Inc Method and apparatus for determining the transmission data rate in a multi-user communication system
US6252851B1 (en) * 1997-03-27 2001-06-26 Massachusetts Institute Of Technology Method for regulating TCP flow over heterogeneous networks
EP0948168A1 (fr) * 1998-03-31 1999-10-06 TELEFONAKTIEBOLAGET L M ERICSSON (publ) Méthode et dispositif pour le contrÔle du flux de données
FI107220B (fi) * 1998-11-06 2001-06-15 Nokia Networks Oy Menetelmä kantajien ominaisuuksien hallitsemiseksi
FI108767B (fi) 1999-02-24 2002-03-15 Ericsson Telefon Ab L M Puhelunmuodostus tietoliikennejärjestelmässä
US6687226B1 (en) * 1999-04-01 2004-02-03 Telefonaktiebolaget Lm Ericsson (Publ) Base station subsystem and method for handling an increase in traffic volume that overloads a terrestrial link in an internet protocol network
US6473442B1 (en) * 1999-04-12 2002-10-29 Telefonaktiebolaget Lm Ericsson (Publ) Communications system and method for matching and balancing the bit rates of transport channels to the bit rate of a physical channel
CN100477701C (zh) * 2000-02-22 2009-04-08 北方电讯网络有限公司 控制无线分组交换语音呼叫的系统及方法
FI20002848A (fi) * 2000-12-22 2002-06-23 Nokia Corp Vuon valvonta tietoliikenneverkossa
US7142508B2 (en) * 2000-12-22 2006-11-28 Radiance Technologies, Inc. System and method for controlling data transfer rates on a network
US7444418B2 (en) * 2001-05-11 2008-10-28 Bytemobile, Inc. Transcoding multimedia information within a network communication system
US20030095510A1 (en) * 2001-11-16 2003-05-22 Motorola, Inc. Use and management of groups defined according to a call initiation protocol
FI116498B (fi) * 2002-09-23 2005-11-30 Nokia Corp Kaistanleveyden mukauttaminen
SE0203056D0 (sv) * 2002-10-11 2002-10-11 Ericsson Telefon Ab L M Method and apparatus in a telecommunication system
US7047310B2 (en) * 2003-02-25 2006-05-16 Motorola, Inc. Flow control in a packet data communication system

Also Published As

Publication number Publication date
CN1774890B (zh) 2010-05-26
EP2099179A1 (fr) 2009-09-09
US20070025301A1 (en) 2007-02-01
ATE484134T1 (de) 2010-10-15
SE0301053D0 (sv) 2003-04-07
CN101516110A (zh) 2009-08-26
EP1614258B1 (fr) 2012-08-01
EP1614258A1 (fr) 2006-01-11
CN1774890A (zh) 2006-05-17
AU2003276592A1 (en) 2004-11-01
CN101516110B (zh) 2011-01-26
WO2004091151A1 (fr) 2004-10-21
ES2390582T3 (es) 2012-11-14
DE60334508D1 (de) 2010-11-18

Similar Documents

Publication Publication Date Title
EP2099179B1 (fr) Methode et systeme de negotiation de debit dans un réseau
US7613147B2 (en) Packet-based conversational service for a multimedia session in a mobile communications system
EP2109266B1 (fr) Méthode et dispositifs pour installer des filtres de paquets dans une transmission de données
KR20160003807A (ko) 모바일 통신 시스템에서 서비스 품질 제어의 지원
EP1856834A1 (fr) Procede de commande de transmission pour transmission bi-directionnelle tcp dans un reseau d'abonnes pre-attribue a largeur de bande asymetrique et appareil correspondant
US20060165126A1 (en) Bit rate controlling means in a telecommunication system
US7221657B2 (en) Processing different size packet headers for a packet-based conversational service in a mobile communications system
US20100299446A1 (en) Method and apparatus for controlling service data flows transmitted in a tunnel
EP3308595B1 (fr) Établissement d'une session d'interaction sur une porteuse dans un réseau de communication radioélectrique
US8004972B2 (en) Quality of service in communication systems
WO2016209131A1 (fr) Établissement d'une porteuse dédiée dans un réseau de communication radio
EP3371948B1 (fr) Établissement d'une session d'interaction sur un support dans un réseau de radiocommunication
US20250088464A1 (en) System and methods for network slicing for coexistence of low latency, low loss and scalable throughput (l4s) and non-l4s traffic in wireless networks
EP4521815A1 (fr) Système et procédés de découpage de réseau pour la coexistence de trafic à faible latence, à faible perte et à débit évolutif (l4s) et non l4s dans des réseaux sans fil
GB2472221A (en) Streaming priority in communications systems

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AC Divisional application: reference to earlier application

Ref document number: 1614258

Country of ref document: EP

Kind code of ref document: P

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

17P Request for examination filed

Effective date: 20100303

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 12/56 20060101AFI20100407BHEP

Ipc: H04L 29/06 20060101ALI20100407BHEP

Ipc: H04W 28/22 20090101ALI20100407BHEP

RIN1 Information on inventor provided before grant (corrected)

Inventor name: CHERMIAKINA, SVETLANA

Inventor name: WESTERLUND, MAGNUS

Inventor name: PETERSSON, JUSTUS

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AC Divisional application: reference to earlier application

Ref document number: 1614258

Country of ref document: EP

Kind code of ref document: P

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REF Corresponds to:

Ref document number: 60334508

Country of ref document: DE

Date of ref document: 20101118

Kind code of ref document: P

REG Reference to a national code

Ref country code: NL

Ref legal event code: VDEP

Effective date: 20101006

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101006

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101006

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101006

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110106

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101006

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101006

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110207

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20101130

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110107

Ref country code: BE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101006

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20101130

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101006

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110117

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20101130

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101006

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

REG Reference to a national code

Ref country code: FR

Ref legal event code: ST

Effective date: 20110801

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101006

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101006

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101006

26N No opposition filed

Effective date: 20110707

PLAA Information modified related to event that no opposition was filed

Free format text: ORIGINAL CODE: 0009299DELT

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20101206

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20101118

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 60334508

Country of ref document: DE

Effective date: 20110707

R26N No opposition filed (corrected)

Effective date: 20110707

RIN2 Information on inventor provided after grant (corrected)

Inventor name: CHERMIAKINA, SVETLANA

Inventor name: WESTERLUND, MAGNUS

Inventor name: SKOG, ROBERT

Inventor name: TERZANI, ALESSIO

Inventor name: PETERSSON, JUSTUS

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101006

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20110407

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20101118

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20101006

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20181128

Year of fee payment: 16

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20181127

Year of fee payment: 16

Ref country code: IT

Payment date: 20181123

Year of fee payment: 16

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 60334508

Country of ref document: DE

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20191118

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20191118

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20191118

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200603