WO2023083763A1 - Procédé de gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement intermédiaire mobile, système et programme d'ordinateur correspondants - Google Patents

Procédé de gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement intermédiaire mobile, système et programme d'ordinateur correspondants Download PDF

Info

Publication number
WO2023083763A1
WO2023083763A1 PCT/EP2022/081021 EP2022081021W WO2023083763A1 WO 2023083763 A1 WO2023083763 A1 WO 2023083763A1 EP 2022081021 W EP2022081021 W EP 2022081021W WO 2023083763 A1 WO2023083763 A1 WO 2023083763A1
Authority
WO
WIPO (PCT)
Prior art keywords
radio
connection
data
mobile intermediate
user equipment
Prior art date
Application number
PCT/EP2022/081021
Other languages
English (en)
Inventor
Jean-Marc Kelif
Emile Stephan
Original Assignee
Orange
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 Orange filed Critical Orange
Publication of WO2023083763A1 publication Critical patent/WO2023083763A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices

Definitions

  • the field of the invention is that of telecommunications.
  • the invention relates to downlink communications, between mobile intermediate equipment (for example a satellite, an airplane, a balloon, a drone, a high altitude platform HIBS ("High Altitude Platform Station”), etc.) and at least one user equipment (or UE for "User Equipment", for example of the "smartphone” type, laptop computer, connected TV, etc.).
  • mobile intermediate equipment for example a satellite, an airplane, a balloon, a drone, a high altitude platform HIBS ("High Altitude Platform Station"), etc.
  • UE for "User Equipment” type, laptop computer, connected TV, etc. for example of the "smartphone” type, laptop computer, connected TV, etc.
  • the invention applies to satellite mobile telephone networks.
  • OFDMA Orthogonal Frequency-Division Multiple Access
  • LTE-A Long Term Evolution – Advanced
  • 5G 5th Generation
  • the invention can also be applied to satellite systems embedding a non-cellular mobile network.
  • 5G offers to cut the Radio Access Network (RAN) into functional blocks, independent of the physical network elements. These are mainly the following functions: a remote radio unit RU (in English “Remote Unit”), a distributed radio processing and scheduling unit DU (in English “Distribution Unit”) and a centralized unit towards the core network CU (in English "Centralized Unit”).
  • a remote radio unit RU in English "Remote Unit”
  • DU distributed radio processing and scheduling unit
  • CU in English “Centralized Unit”
  • splits have been proposed, according to the objectives of concentration of the functions of the RAN.
  • the F1 interface between the CU and DU functions also known as HLS (Higher Layer Split), is specified in part by 3GPP.
  • HLS Higher Layer Split
  • the O-RAN standardization alliance has notably defined deployment scenarios in which the F1 interface is fully interoperable.
  • the F2 interface between the DU and RU functions also called LLS ("Lower Layer Split") or "Open FrontHaul" is an open interface (unlike a CPRI type interface ("Common Public Radio Interface”) typically used between a base station and its antennas). It is also specified by 3GGP, in particular for variant 7.2.
  • Non Terrestrial Network based on the use of non-terrestrial equipment for radio access (“Non Terrestrial Network"), such as satellites, planes or even balloons have been proposed.
  • satellite RAN implementing two satellites SAT1 and SAT2.
  • Each of these satellites generates at least one radio beam, also called a spot.
  • the terrestrial geographic zone covered by this radio beam corresponds to a radio cell, benefiting from radio coverage. It can therefore be considered that a satellite emulates a radio cell.
  • a radio cell is called RaF hereafter, for Emulated Fixed Terrestrial RAN.
  • such a radio cell can be associated with at least one cell identifier.
  • a user equipment UE can connect to a server S, for example a web server, via the radio network RAN comprising the satellite SAT1 which embeds the RU and DU functions according to the architecture illustrated, and a station terrestrial GW1 (in English "terrestrial gateway") which embeds the CU function, managed for example by a network operations center NoC (in English "Network Operations Center”) which brings together the operator of the mobile network MNO (in English " Mobile Network Operator”) and the satellite network operator SNO ("Satellite Network Operator"). Routers between different communication networks (regional network, national network for example) between ground station GW1 and server S are shown with an "X".
  • all or part of the virtualized functions (RU, DU, CU) of the satellite RAN can be distributed over one or more satellites of a constellation and one or more ground stations.
  • the satellite RAN involves at least one additional radio connection, for example of the e-CPRI type, in order to connect the satellite to the terrestrial station then to the core of the mobile network, or even more when the Virtualized functions are spread across multiple satellites, with the use of ISL (Inter Satellite Link) links between satellites.
  • ISL Inter Satellite Link
  • the distance between these virtualized functions must be minimized to meet the deadlines established for 5G.
  • the latency between the RU function and the DU function must be less than one millisecond.
  • the system is less sensitive to the latency between the satellite and the earth station, at least with regard to the mobile radio processing.
  • the CU function can also be placed in the satellite constellation, in the ground station or even in remote data center equipment.
  • the ability of a satellite to emulate a terrestrial 5G cell is limited. Indeed, due to the distance between the satellite and the user equipment (for example 500 km for a satellite RAN instead of 5 km for a terrestrial RAN) and/or the angle of the radio beam emulating the radio cell, the size of the emulated cell is very large (for example 50km in diameter for a RaF radio cell emulated by a satellite RAN instead of 5km in diameter for a terrestrial cell associated with a terrestrial antenna).
  • the invention proposes a solution that does not have all the drawbacks of the prior art, in the form of a method for managing communications in a communications network implementing at least one mobile intermediate device generating at least one beam radio covering a terrestrial geographical area, called a radio cell.
  • individual phase is meant here a set of radio resources of the data stream of the radio beam, used for transmissions between the mobile intermediate equipment and the radio cell, making it possible to reach a target rate. More generally, if the stream has N individual phases ( ), this means that it has radio resources available for transmissions between the mobile intermediate equipment and the radio cell making it possible to reach N target bit rates. For example, two users present in the radio cell can simultaneously receive the data stream carrying on the one hand connection start data at a first target rate coming from the first data server, and on the other hand start data connection at a second target rate from a second data server. Target rates may be different.
  • the invention thus proposes to estimate the capacity of a radio cell emulated by a radio beam, i.e. the number of user equipments that can simultaneously receive data with a target rate, corresponding to the number of individual phases of the data stream.
  • a radio cell emulated by a radio beam i.e. the number of user equipments that can simultaneously receive data with a target rate, corresponding to the number of individual phases of the data stream.
  • the proposed solution thus makes it possible, according to at least one embodiment, to improve the quality of the user experience by accelerating the start of connections.
  • the remainder of the radio bandwidth, not used by the individual phase(s), may be used by other user equipment connections, including for the transmission of connection "tracking" data.
  • the proposed solution thus makes it possible, according to at least one embodiment, to make efficient use of the entire radio bandwidth.
  • a target speed from the start of the connection of approximately 8 Mbps (i.e. a volume of 2 Megabytes of data for a duration 2 seconds) to support interactions at a high enough rate to maintain user attention and trust.
  • the necessary speed depends on the uses and the activity of the user. It is often less given the reuse of data downloaded at the start of connections by the Web application (CSS, javascript libraries, cached images, etc.), and the data processing time (for example the concentration of the attention of the user on the current page).
  • the transmission of data between the mobile intermediate equipment and the user equipment can be carried out at the target rate of the individual phase until a stop criterion, then at a rate lower than the target rate.
  • these different steps can be implemented by the same equipment (for example equipment managed by the operator of the intermediate equipment or equipment managed by the operator of the user equipment).
  • these steps can be implemented by different equipment (for example the steps for obtaining the number of individual phases and detecting the start of a connection can be implemented by at least one device managed by the operator of the user device, and the steps of transmission by at least one device managed by the operator of the intermediate device).
  • the capacity of a radio cell therefore depends on the characteristics of the radio beam generated by the intermediate equipment.
  • such intermediate equipment is mobile, i.e. distinct from a fixed ground station. It is for example terrestrial equipment or non-terrestrial equipment, such as a satellite, an airplane, a balloon, a drone, an HIBS etc.
  • Such intermediate equipment is also called access equipment, in that it can be connected directly to user equipment (i.e. without passing through a fixed terrestrial antenna).
  • the number of individual phases of the flux is equal to the integer part of the capacitance of the radio beam generated by the mobile intermediate equipment:
  • the decimal part of the capacity corresponds to the remaining bit rate for transmissions outside the individual phase(s), known as “tracking”.
  • the solution proposed according to this embodiment thus makes it possible to simply determine the distribution of the radio resources of the stream, between the individual phase(s) and the rest of the stream.
  • the distribution according to this embodiment is done by an integer division and a modulo.
  • connection continuation generally requires a lower bit rate than "connection start”.
  • connection start generally requires a lower bit rate than "connection start”.
  • the release of an individual phase of the flow allows another user equipment to benefit from the target bit rate at the start of the connection (or the first user equipment to benefit from the target bit rate at the start of the connection for a new connection).
  • the criterion for stopping a transmission at the target rate of an individual phase depends on a type of service or on the domain requested.
  • the time allocated for the individual phase may be longer, for example of the order of 4 to 10 seconds, or the volume of data allocated for the individual phase may be greater, for example of the order of 4 to 10 megabytes.
  • the number of individual phases of the stream can thus be adjusted dynamically, in particular asynchronously.
  • the number of individual phases can be increased following a need of the 5G core network due to saturation or an incident on a terrestrial cell belonging to the geographical terrestrial zone covered by the radio beam.
  • the step of detecting the start of a connection implements the detection of an exchange of connection securing data between said first user equipment and said first data server.
  • the proposed solution thus encourages the exposure of the end-to-end signaling of the connections.
  • the method implements the storage of information relating to said at least one individual phase in an individual phase management table.
  • the invention also relates to a communication management system in a communication network implementing at least one mobile intermediate device generating at least one radio beam covering a terrestrial geographical area, called a radio cell.
  • such a system includes one or more devices managed by the operator of the intermediate device (for example the satellite operator) and/or the operator of the user device.
  • modules for obtaining the number of individual phases and for detecting a start of connection belong to at least one device managed by the operator of the user device, and the transmission modules belong to at least one device managed by the operator of the intermediate equipment.
  • certain modules can be located on different satellites.
  • these different modules correspond to functional blocks, which can be co-located or remote.
  • the invention also relates to one or more computer programs comprising instructions for the implementation of a communication management method as described above when this or these programs are executed by at least one processor.
  • radio access network architecture comprising a satellite
  • radio access network architecture comprising a satellite according to one embodiment of the invention
  • the invention is placed in the context of a communication network implementing mobile intermediate transmission equipment (i.e. at least one radio antenna which moves, for example a satellite, an airplane, a balloon, a drone, a HIBS , etc.), and proposes a solution to improve communications via the mobile intermediate transmission equipment.
  • mobile intermediate transmission equipment i.e. at least one radio antenna which moves, for example a satellite, an airplane, a balloon, a drone, a HIBS , etc.
  • the general principle of the invention is based on the estimation of the number of individual phases available in the data stream of the radio beam generated by the intermediate mobile transmission equipment and emulating a radio cell, and on the allocation of a phase individual at the start of the connection (if an individual phase is available) allowing data to be transmitted at a desired bit rate (known as the target bit rate) at the start of the connection.
  • the proposed solution thus makes it possible to accelerate the start of connections.
  • a first step 41 the number of individual phases, each associated with a target rate in the stream, to be used for transmissions from the mobile intermediate equipment to the radio cell is obtained.
  • a first user equipment present in the radio cell, connects with a first data server, via the mobile intermediate equipment.
  • connection start data from the first data server can be transmitted, between the mobile intermediate equipment and the first user equipment, at the target rate of the individual phase, up to a stopping criterion.
  • connection start data from the first data server can be transmitted, between the mobile intermediate equipment and the first user equipment, at a rate lower than the rate individual phase target.
  • the radio bandwidth is used efficiently, by reserving part of the bandwidth for the start of a connection and the rest of the bandwidth for the continuation of the connections.
  • the mobile intermediate equipment is considered to be a satellite, managed by a satellite network operator SNO.
  • a satellite is called an access satellite, in that it can connect directly to user equipment.
  • the SNO for example the OSS ("Operations Support System"), configures a satellite RAN.
  • a satellite can generate one or more radio beams, also called spots.
  • the characteristics of the satellite, or the radio beams of the satellite can be defined from different parameters: Setting Definition spot emission power frequency-dependent propagation factor bandwidth (MHz) of the spot , with the target rate (Mbps) of an individual phase of the stream number of interfering spots shadowing standard deviation (dB) , thermal noise at the receiver (constant) satellite - receiver distance aperture angle of spot transmitting antenna, typically 2 to 5 degrees
  • parameters can be different for each spot generated by the satellite.
  • certain parameters may be linked to the physical characteristics of the equipment (satellite in particular), to the characteristics desired by the mobile network operator MNO (for example a reception rate of 5Mbps at the start of the connection for a user equipment, etc.), etc
  • the parameters P of emission power of the spot, W of bandwidth of the spot can be chosen by the SNO, and the parameter corresponding to the target rate of an individual phase can be chosen by the MNO.
  • the SNO OSS collects the various satellite state information (main states and main propagation characteristics) and needs (coming for example from the MNOs) and stores them in a table.
  • spot_ID _EU 1 45dBm 10MHz 5 Mbps 6 mW 500km 2 50dBm 10MHz 6 Mbps 6 mW 600km ... 50dBm 10MHz 5 Mbps 6 mW 700km 1000 55dBm 10MHz 5 Mbps 6 mW 600km
  • This table can in particular be exchanged between the OSS of the SNO and the satellite.
  • the number of individual phases of a spot data stream can be determined from one or more parameters defined in the tables above.
  • the number of individual phases of the flow is equal to the integer part of the capacitance of the radio beam, such as:
  • the proposed solution makes it possible to establish the capacity of a spot using the expression (1) above.
  • This capacity characterizes the number of user equipment simultaneously receiving data with the target rate . In other words, this expression meets the constraints in terms of minimum throughput to be achieved by each user equipment.
  • the capacity can also be expressed in the following form:
  • the decimal part of the capacity is the remaining throughput for transmissions outside of the individual phase(s).
  • the parameters in particular the probability of non-hedging , can be adjusted to increase the number of individual phases when necessary.
  • the probability of non-coverage can in particular be chosen from a list of possible values ( ; etc). This different information can be added to the spot status table.
  • Spot_ID Comment 1 2 belonging to an interval allowing to obtain if possible 2 individual phases 2 ; 1 belonging to an interval allowing to obtain a single individual phase ... 1000 ;
  • At least one individual phase denoted DebCo, serving the data from the start of each connection
  • a so-called “common” phase denoted ContCo, grouping the following data from existing connections .
  • the values of , , And can be dynamically adjusted to optimize statistical multiplexing.
  • a connection to a domain video.example.com may take twice as long to start. or megabytes compared to default values.
  • the OSS of the MNO or the SNO can in particular update these parameters for the existing connections in progress. For example, if a user equipment connects to an emergency service, the OSS may shorten (at least temporarily) the duration of an individual phase of an existing connection, to release the individual phase of the existing connection. In this way, the satellite can recover the individual phase for the start of connection of the user equipment with the emergency service.
  • the SNO OSS can in particular communicate this spot status table to the satellite.
  • an RRC module seeks to detect new connections in the stream of IP packets received at the input of the satellite, based on the connection start signalling, the size, the encoding, the the time signature of the packets, fields of the IP packet headers identifying the IP flow (source address, destination address, protocol, source port, destination port, etc.).
  • a step can be implemented by an RLC module (in English “Radio Link Control”), or even MAC.
  • a user device present in the radio cell seeks to connect to a website myexample.com, hosted on a data server.
  • a negotiation phase is typically implemented between the user equipment and the data server, via the satellite if we consider a satellite RAN.
  • a "Handshake TLS" type process is implemented between the user equipment and the data server, via the satellite. This process includes an unencrypted phase when downloading certificates.
  • the RRC module can thus detect the different phases of secure connections of the QUIC, TLS, DTLS, EDHOC and similar protocols, and detect the start of an internet connection.
  • the RRC module can identify from the size, the encoding, and/or the presence of a "ClientHello" type message the phases transporting the certificates corresponding to a first connection (QUIC 1-RTT), reconnection phases with resumption of sessions (resumption of the context of the previous connection, called QUIC 0-RTT crypto).
  • the RRC module can thus detect the start of a new connection.
  • the RRC module can also classify the packets received (as being to be transmitted on an individual phase or on a common phase) from the start of connection signalling, the size, the encoding, the time signature of the packets, etc.
  • the RRC module can identify from the presence of a "ClientHello" type message the phases transporting the certificates corresponding to a first connection (QUIC 1-RTT), reconnection with resumption of sessions (resumption of the context of the previous connection, called QUIC 0-RTT crypto) and classify the 1-RTT phases to transmit them on an individual phase and the 0-RTT phases to transmit them on a common phase.
  • QUIC 1-RTT reconnection with resumption of sessions
  • QUIC 0-RTT crypto classify the 1-RTT phases to transmit them on an individual phase and the 0-RTT phases to transmit them on a common phase.
  • a connection can be identified at level 3 (source address, destination address, protocol, source port, destination port, etc.).
  • the RRC module can transmit a connection start indicator DebCoFlag to the RLC module during a step 521, or directly to the MAC module during a step 522.
  • connection start indicator can be intended for the RLC module.
  • a connection start indicator can be inserted in a proprietary header or in place of an unused bit, for example a reserved bit of the QUIC protocol, for example the "spin bit".
  • a connection start indicator can alternatively be inserted in a non-proprietary message, for example the iOAM ("In-situ OAM") header, an ECN ("Explicit Congestion Notification”) message, etc. .
  • such a connection start indicator is sent directly to the MAC module.
  • connection start indicator makes it possible to identify the packets of the IP streams received by the satellite which must be transmitted in the individual phase or phases at the output of the satellite.
  • a FinCoFlag end of connection indicator can be transmitted to the RLC module or to the MAC module.
  • DebCoDuration or DebCoVol volume information can be transmitted to the RLC module or to the MAC module. It is thus possible to mark all the successive packets as being to be transmitted on an individual phase, or only the first and the last packet concerned.
  • connection start flag DebCoFlag may be an integer corresponding to DebCoDuration or to DebCoVol.
  • This FinCoFlag end of connection flag or this DebCoDuration or DebCoVol information, can be used to determine when to stop transmission in the individual phase(s) out of the satellite.
  • connection start flag intended for the RLC module if the RLC module receives a DebCoFlag connection start flag, it can add it (54) in the first frames (or "subframes") ) intended for the MAC module, then transmit the first frames with the DebCoFlag connection start flag.
  • the DebCoFlag connection start flag is an integer corresponding to the DebCoDuration duration, it can be decremented over time (for example, if DebCoDuration is 5 seconds, the first frame carries the flag 5, the second frame carries the flag 4, ..., the fifth frame bears the flag 1 and the sixth frame bears no flag).
  • the DebCoFlag connection start flag is an integer corresponding to the DebCoVol volume, it can be decremented by taking into account the size of each frame.
  • the RLC module no longer marks the frames (i.e. no longer inserts an indicator in the frames).
  • the RLC module in the absence of radio resources, does not transmit the unmarked frames to the MAC module.
  • the RLC module does not forward untagged frames to the MAC module. These frames are considered discarded or "garbaged”.
  • the RLC module does not receive a DebCoFlag connection start indicator, it can directly transmit the first frames to the MAC module, without marking them.
  • the MAC module Upon receipt of the frames marked according to the first example presented above (start of connection indicator intended for the RLC module), the MAC module detects the start of connection indicator inserted in the frames by the RLC module, and sends (55) the frames in the individual phase of the data stream.
  • the MAC module identifies the connection start data from at least one marker/indicator inserted by the RRC module in at least one data packet coming from the first data server (first frames).
  • the MAC module can thus insert the connection start data into the individual phase of the radio beam stream.
  • the MAC module receives on the one hand unmarked frames from the RLC module and on the other hand the connection start indicator coming from the RRC module according to the second example presented above (connection start indicator intended directly for the MAC module), it can directly transmit (55) the frames identified from the start of connection indicator in the individual phase of the data stream.
  • the MAC module can send the remaining frames in the common phase (i.e. with a rate lower than the target rate) if it has resources left.
  • the MAC module in the absence of radio resource, does not transmit the remaining frames. These frames are considered discarded or "garbaged".
  • the RRC, RLC and MAC modules are co-located in the satellite.
  • the RRC module and/or the RLC module can be remote, and in particular located in fixed terrestrial equipment.
  • An example of use of the method by an MNO consists in using the capacity of a satellite RAN during a planned maintenance operation of a terrestrial RAN (for example change of card, restart, etc.). This operation can be carried out at night during off-peak hours.
  • the satellite RAN must have a minimum capacity sufficient to replace the terrestrial RAN, in particular to provide speed to the emergency services.
  • a satellite SAT generates a radio beam 61 emulating a radio cell (RaF), in which three user equipments UE1, UE2 and UE3 are present.
  • RaF radio cell
  • the satellite SAT is connected to the terrestrial network 62 (comprising the satellite network operator SNO and the mobile network operator MNO) via a terrestrial gateway GW.
  • the user equipment UE1, UE2 and UE3 can connect to one or the other of the servers S1, S2 and/or S3 via the satellite SAT.
  • the SNO OSS configures the SAT satellite.
  • the MNO OSS transmits "bootstrapping" and configuration type messages to the various modules of the SAT satellite (RRC, RLC and MAC in particular).
  • the MNO wishes to carry out the maintenance of a RAN whose cell is at the geographical position Pgeo.
  • the 5G core of this MNO requires the creation of a RaF RaF1 (61) whose characteristics are described by an entry in a spot state table, such as table 2 presented above.
  • the RaF RaF1 therefore implements a single individual phase associated with a target rate.
  • the bit rate not used by the individual phase of the data stream is used by a so-called common phase.
  • the SNO can thus generate the RaF1 in the satellite with these values.
  • the SNO can also create an individual phase management table, allowing the individual phase(s) of the RaF1 radio beam data stream to be tracked.
  • Such a management table can also be provided in the spot state table.
  • control loop the MNO collects the various information on the states of the satellite and the needs (for example , , , , etc) and sends them to the SNO.
  • the SNO can in particular determine the capacity of the Raf Raf1 from this information.
  • the MNO can also complete and/or update the individual phase management table with these different values.
  • the values of , , And can be dynamically adjusted to optimize statistical multiplexing. This is an adjustment range of each parameter from the nominal value.
  • the step of estimating the number of new connections to be served by the satellite RAN generates five scenarios using analytical processing by playing on the values of , , And by varying their values, for example from 1 to 5% in steps of 1%. For example, it is possible to increase , to tend towards a value of of 2. The algorithm can try to get closer to the value without trying to reach it.
  • the satellite and the SNO can update the status table / spot management table with these different values (73).
  • the individual phase management table contains in particular the control information for the individual phase or phases. It is used to exchange both control information and instances of individual phases.
  • the first line of values shows the control parameters for an individual phase.
  • the following lines describe the progress of the individual phases. Flow Raf1 Number of free individual phases (or instance type) Total number of individual phases (or used by an instance) (Mbps) (s) (MB) Control 1 1 5 3 3
  • Table 3 Individual Phase Management Table
  • phase management table does not necessarily contain information on the common phase. In this way, the size of the management table remains small, and its transmission remains inexpensive. However, in order to facilitate the understanding of the invention, the information on the common phase is specified in the table in the remainder of the description.
  • three user equipments (UE1, UE2 and UE3, as illustrated in ) connect to the RaF1.
  • UE1, UE2 and UE3, as illustrated in connect to the RaF1.
  • they may or may not have an individual phase.
  • the user equipment UE1 has the individual phase of the flow for a duration Ti_1
  • the user equipment UE3 has the individual phase of the flow for a duration Ti_3, which does not overlap Ti_1.
  • the user equipment UE2 does not have the individual phase.
  • the user equipment UE1 wishes to establish a connection with the server S1.
  • UE1 sends a "ClientHello” message CHO ("Connection UE1.Cnx1 end to end starts: ClientHello 1 RTT phase") to server S1, and the server responds with a "ServerHello” message SHO ( "Connection UE1.Cnx1 end to end signaling: ServerHello”).
  • the RRC module can notably identify the different phases of the secure connections of the QUIC, TLS, DTLS, EDHOC and similar protocols, by detecting the presence of the initial signaling ("handshake").
  • the TLS handshake of an HTTPS connection (same for QUIC and DTLS and EDHOC) includes an unencrypted part in the "ClientHello" message, in particular the so-called 1-RTT phase which includes the downloading of certificates.
  • the RRC module distinguishes from the presence of the "ClientHello" message the phases transporting the certificates (QUIC 1-RTT phase) from the reconnection phases with resumption of sessions (resumption of the crypto context, called 0-RTT, of the previous connection).
  • the RRC module can therefore detect a new UE1.CNX1 connection in the IP stream or streams received by the satellite.
  • the OSS of the SNO or the satellite checks whether an individual phase is free for the transmission of connection start data from the satellite to the user equipment UE1 by consulting the table for managing the individual phases of the spot.
  • UE2 wishes to establish a connection with the server S1 or the server S2. For example, UE2 sends a message of type "ClientHello" to server S2.
  • the RRC module detects this new UE2.CNX1 connection in the IP streams received by the satellite, for example one second after the start of the UE1.CNX1 connection.
  • the OSS of the SNO or the satellite checks whether an individual phase is free for the transmission of connection start data from the satellite to the user equipment UE2 by consulting the table for managing the individual phases of the spot.
  • connection start data originating from the server S2 is therefore transmitted from the satellite SAT to the user equipment UE2 at a rate lower than the target rate of the individual phase.
  • the packets of the UE2.CNX1 connection are exchanged in the common phase of the stream.
  • the individual phase is released and available for another transmission.
  • UE3 wishes to establish a connection with the server S3. For example, UE3 sends a "ClientHello" type message to the S3 server.
  • the RRC module detects this new UE3.CNX1 connection in the IP streams received by the satellite, for example 4 seconds after the start of the UE1.CNX1 connection.
  • Table 7 Individual Phase Management Table
  • the choice of signal transport depends in particular on the location of the RLC, RRC and MAC blocks, which depends on the "split" chosen and/or the manufacturers of these blocks. For example, in the case of split eCPRI A or B (3GPP option 1 or 2) and an implementation of the MAC block and the RRC block by different manufacturers, this signal is preferentially transported in a predetermined way between these blocks.
  • connection start signal is for example added by the RLC module in the first frames of the packets carrying the connection start data received from the server S1 (UE1.Cnx1_data).
  • connection indicator FinCoFlag can be transmitted (77) to the RLC module or to the MAC module.
  • connection start flag DebCoFlag and the connection start flag FinCoFlag are transmitted in separate signals, and mark only the first and last packet carrying connection start data received from server S1. These signals can be sent directly to the MAC module.
  • DebCoDuration or DebCoVol volume information can be transmitted to the RLC module or to the MAC module.
  • the DebCoDuration duration information corresponds in particular to the duration of an individual phase as defined in the individual phase management table.
  • the DebCoVol volume information corresponds in particular to a volume of data to be transmitted in an individual phase as defined in the individual phase management table.
  • the connection start indicator DebCoFlag can be an integer corresponding to the duration information DebCoDuration and therefore decremented over time.
  • the DebCoFlag connection start indicator corresponds to the DebCoVol volume information and is therefore decremented with the size of each frame of the accelerated packets.
  • the MAC module On reception of the frames, the MAC module checks for the presence of a DebCoFlag connection start signal. If a DebCoFlag connection start signal is detected, it transmits the corresponding data in the individual phase of the stream of the spot (781). Otherwise, it transmits the frames in the common phase of the spot stream, if it has radio resources in transmission. Otherwise, the frames can be buffered or "garbaged" by the MAC module.
  • the RLC module After the DebCoDuration time or the DebCoVol volume, or upon receipt of a FinCoFlag end of connection signal, the RLC module no longer marks the frames (79).
  • the MAC module therefore transmits the frames carrying "connection pursuit" data in the common phase of the spot stream (782), if it has radio resources in transmission. Otherwise, the frames can be buffered or trashed by the MAC module.
  • the RLC module can buffer or "bind" untagged frames depending on the type of RLC module (Transparent Mode (TM), Unacknowledged Mode (UM), or Acknowledged Mode (AM)).
  • TM Transparent Mode
  • UM Unacknowledged Mode
  • AM Acknowledged Mode
  • the MAC module can directly transmit the frames carrying data received from the server S1 in the common phase of the stream of the spot.
  • the mobile intermediate equipment is a satellite.
  • Other mobile access equipment can of course be used, for example an airplane, balloon, drone, HIBS, etc.
  • RRC, RLC and MAC modules are co-located in the mobile intermediate equipment.
  • some modules can be located remotely.
  • the different signals exchanged (connection start and/or end indicator, tables, etc.) must have a format compatible with the different modules in order to be processed.
  • the invention can be implemented in the various architectures described in relation to the (“Nothing on board”, “RU onboard”, “RU+DU onboard”, “RU+DU+CU onboard”).
  • the OSS of the MNO can update certain parameters, in particular for the existing connections in progress on the individual phase.
  • the capacity calculation algorithm presented above proposes to shorten the duration of an individual phase to respond to the arrival of several new user equipments in the radio cell, in addition to UE1, then the duration of the connection in progress UE1.CNX1 can be reduced, for example by 5%, to accept the connection UE2.CNX2 a little earlier in the individual phase.
  • the duration of the connection in progress UE1.CNX1 can be forced by the OSS of the MNO or the SNO, for example to 95%, to accelerate the transition to the common phase of the transmission, in order to immediately accept the UE2.CNX2 connection to the emergency service in the individual phase.
  • parameters can be chosen or updated taking into account the service or the domain of the requested server.
  • a connection to a domain video.example.com may take twice as long to start. or megabytes .
  • the RRC module can classify 1-RTT phases to transmit the corresponding data on an individual phase of the stream, and 0-RTT phases to transmit them on an individual phase of the stream. common phase.
  • the initial phases of QUIC 0-RTT connections can also be transmitted on an individual phase of the stream if such an individual phase is available.
  • This individual phase can have different parameters (in particular , and or ), for example with a faster switchover to the common phase ( For example). This reduction takes into account the lower need for data at the start of reconnection due to the presence of application data in the cache of the user equipment.
  • the CN Common Name
  • SAN Subject Alternative Name
  • the RRC module can be used by the RRC module or one of the BSSs to identify a CDN partner, type of service or a domain name, and associate a custom control with it.
  • these parameters differ with the service or domain of the requested server.
  • the BSS can provide these rules to the RRC module in a personalization table of the individual phases. This implementation allows the classification of the connection as soon as the connection is detected.
  • a connection to a video.example.com domain gets double the startup time or megabytes .
  • the domain foo.example.com will still be classified for transmission in the common phase.
  • connections coming from the IP subnet 192.168.1.0/24 or from the samu.example.com domain preempt the connections in progress on the individual phase, without taking the resources of the common phase, with an infinite duration and an unlimited volume . service (Mbps) (s) (MB) video.example.com 5 6 6 foo.example.com 0 0 0 Source IP 192.168.1.0/24 5 0 0 Source domain samu.example.com 10 0 0 0
  • Table 8 Individual Phase Customization Table
  • a "service" column receiving the domain of the connection can be added to the individual phase management table so that the MNO's OSS/BSS applies these rules to the connections in progress.
  • This implementation allows the classification of the connections in progress after reception of the table of management of the individual phases.
  • CNX1 Flow Raf1 Number of free individual phases or instance type Total number of individual phases (or used by an instance) (Mbps) (s) (MB) Service Control 0 1 5 3 3 UE1.
  • CNX1 Individual 1 5 2 2 video.example.com UE2.CNX1 commmon 0 0 0 0 foo.example.com
  • Table 9 Individual phase management table after customization, received from RaF1 one second after the start of the UE1.CNX1 connection Flow Raf1 Number of free individual phases or instance type Total number of individual phases (or used by an instance) (Mbps) (s) (MB) Service Control 0 1 5 3 3 UE1.CNX1 individual 1 5 5 5 5 5 video.example.com UE2.CNX1 commmon 0 0 0 0 foo.example.com UE2.CNX1 commmon 0 0 0 0 foo.example.com
  • Table 10 Individual phase management table after customization, sent by OSS/BSS to RaF1
  • Table 7 Individual phase management table after customization
  • the transmission with the first user equipment UE1.CNX1 is always in the individual phase of the stream of the spot.
  • the transmission with the third user equipment UE3.CNX1 is in the common phase of the flow, since the number of free individual phases is always at zero.
  • the choice of the implementation of the customization above depends on the location of the RRC block of the centralized unit CU.
  • An "embedded" location of the CU (remote from the OSS/BSS) implies the choice of a common transport mode (a standardization) of the individual phase customization table / post-customization individual phase management table.
  • these modules can be co-located within the same equipment (for example equipment managed by the mobile operator or by the satellite operator), or remote.
  • At least one item of equipment of such a system comprises at least one memory 81 comprising a buffer memory, at least one processing unit 82, equipped for example with a programmable calculation machine or a dedicated calculation machine, for example a processor P, and controlled by the computer program 83, implementing steps of the communications management method according to at least one embodiment of the invention.
  • the code instructions of the computer program 83 are for example loaded into a RAM memory before being executed by the processor of the processing unit 82.
  • these different steps can be implemented by physical or software modules, co-located or remote.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé de gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement intermédiaire mobile générant au moins un faisceau radio couvrant une zone géographique terrestre, dite cellule radio, mettant met en œuvre les étapes suivantes, pour un flux de données dudit au moins un faisceau radio : - obtention (41) du nombre de phases individuelles associées chacune à un débit cible dans ledit flux, pour des transmissions dudit équipement intermédiaire mobile vers ladite cellule radio, - détection (42) d'un début de connexion d'un premier équipement utilisateur, présent dans ladite cellule radio, avec un premier serveur de données, via ledit équipement intermédiaire mobile, - si une phase individuelle est disponible pour ledit flux : transmission (431) de données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, au débit cible de la phase individuelle, jusqu'à un critère d'arrêt, - si aucune phase individuelle n'est disponible pour ledit flux : transmission (432) de données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, à un débit inférieur audit débit cible.

Description

Procédé de gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement intermédiaire mobile, système et programme d’ordinateur correspondants
1. Domaine de l’invention
Le domaine de l’invention est celui des télécommunications.
Plus précisément, l’invention concerne les communications en voie descendante, entre un équipement intermédiaire mobile (par exemple un satellite, un avion, un ballon, un drone, une plateforme de haute altitude HIBS (« High Altitude Platform Station »), etc) et au moins un équipement utilisateur (ou UE pour « User Equipment », par exemple de type « smartphone », ordinateur portable, TV connectée, etc).
A titre d’exemple, l’invention s’applique aux réseaux de téléphonie mobile satellitaires.
Elle peut notamment, mais non exclusivement, s’appliquer aux systèmes cellulaires fondés sur une technologie d’accès de type OFDMA (en anglais « Orthogonal Frequency-Division Multiple Access »), tels que le LTE-A (en anglais « Long Term Evolution – Advanced) ou la 5G. L’invention peut également s’appliquer aux systèmes satellitaires embarquant un réseau mobile non cellulaire.
2. Art antérieur
Contrairement aux générations précédentes, la 5G propose de découper le réseau d’accès radio (RAN, en anglais « Radio Access Network ») en blocs fonctionnels, indépendants des éléments de réseau physiques. Il s’agit principalement des fonctions suivantes : une unité radio distante RU (en anglais « Remote Unit »), une unité distribuée de traitement et ordonnancement radio DU (en anglais « Distribution Unit ») et une unité centralisée vers le cœur de réseau CU (en anglais « Centralized Unit »). Plusieurs variantes de répartition de ces fonctions, appelées « splits » ont été proposées, suivant les objectifs de concentration des fonctions du RAN.
Il convient néanmoins de trouver un compromis entre les bénéfices de la centralisation et le coût des liaisons supplémentaires induites par la répartition de ces fonctions sur plusieurs éléments de réseau physiques, notamment les liaisons entre les fonctions DU et RU. En effet, chaque split a une contrainte de débit et de latence.
La présente une famille de « splits » dite intra couche physique connue de l’état de la technique (variantes 8, 7.1, 7.2 et 7.3 ), où CN correspond au cœur de réseau (en anglais « Core Network »), BH à la liaison entre le cœur de réseau et la fonction CU (en anglais « Backhaul »), MH la liaison entre les fonctions CU et DU (en anglais « Midhaul ») et FH la liaison entre les unités DU et RU (an anglais « Fronthaul »). Selon cette famille, les opérations de codage ENC/décodage DEC, de poinçonnage PUNCT/ dé-poinçonnage DE-PUNCT peuvent être mises en œuvre par la fonction DU. Les opérations de modulation MOD / démodulation DEMOD, mappage des éléments de ressource RE-MAP et démappage RE-DEMAP, et transformation IFFT / FFT peuvent être mises en œuvre par la fonction RU.
Cette famille de « splits » intra couche physique est particulièrement étudiée, grâce aux bénéfices de coopération radio entre cellules qui permettrait de réduire les interférences et augmenter le débit utilisateur (formation de faisceau – en anglais « beamforming », transmission conjointe – en anglais « joint transmission », multi-trajets – en anglais « multi-paths », etc).
La illustre les interfaces entre les fonctions réseau virtualisées CU, DU et RU.
L’interface F1 entre les fonctions CU et DU, également appelée HLS (en anglais « Higher Layer Split »), est spécifiée en partie par le 3GPP. L’alliance de normalisation O-RAN a notamment défini des scenarii de déploiement dans lesquels l’interface F1 est entièrement interopérable.
L’interface F2 entre les fonctions DU et RU, également appelée LLS (en anglais « Lower Layer Split ») ou « Open FrontHaul », est une interface ouverte (à la différence d’une interface de type CPRI (en anglais « Common Public Radio Interface ») classiquement utilisée entre une station de base et ses antennes). Elle est aussi spécifiée par le 3GGP notamment pour la variante 7.2.
En parallèle, et afin notamment d’améliorer la couverture radio dans certaines zones géographiques, des architectures de réseau 5G basées sur l’utilisation d’équipements non-terrestres pour l’accès radio (en anglais « Non Terrestrial Network »), comme des satellites, des avions ou encore des ballons, ont été proposées.
La illustre un exemple de RAN satellitaire, mettant en œuvre deux satellites SAT1 et SAT2. Chacun de ces satellites génère au moins un faisceau radio, également appelé spot. La zone géographique terrestre couverte par ce faisceau radio correspond à une cellule radio, bénéficiant d’une couverture radio. On peut donc considérer qu’un satellite émule une cellule radio. Une telle cellule radio est appelée RaF par la suite, pour RAN terrestre fixe émulé. En particulier, une telle cellule radio peut être associée à au moins un identifiant de cellule.
Selon cet exemple, un équipement utilisateur UE peut se connecter à un serveur S, par exemple un serveur web, par l’intermédiaire du réseau radio RAN comprenant le satellite SAT1 qui embarque les fonctions RU et DU selon l’architecture illustrée, et une station terrestre GW1 (en anglais « terrestrial gateway ») qui embarque la fonction CU, gérée par exemple par un centre d’opérations du réseau NoC (en anglais « Network Operations Center ») qui regroupe l’opérateur du réseau mobile MNO (en anglais « Mobile Network Operator ») et l’opérateur du réseau satellite SNO (en anglais « Satellite Network Operator »). Les routeurs entre différents réseaux de communication (réseau régional, réseau national par exemple) entre la station terrestre GW1 et le serveur S sont illustrés par un « X ».
Différentes architectures de RAN satellitaire peuvent être mises en œuvre :
  1. « Nothing onboard », i.e. les différentes fonctions sont mises en œuvre par des équipements terrestres :
    1. la fonction DU et la fonction RU sont co-localisées dans la station terrestre, et la fonction CU dans un centre de données (« data center ») distant du MNO,
    2. la fonction DU et la fonction CU sont co-localisées dans un centre de données distant du MNO, et la fonction RU co-localisée avec la station terrestre,
  2. « RU onboard » : i.e. la fonction RU est mise en œuvre par le satellite :
    1. la fonction DU et la fonction CU sont distantes, et la fonction RU localisée dans le satellite,
    2. la fonction DU est co-localisée avec la station terrestre, la fonction CU est distante, et la fonction RU localisée dans le satellite,
  3. « RU+DU onboard », i.e. les fonctions RU et DU sont mises en œuvre par le satellite :
    1. les fonctions RU et DU sont localisées dans le satellite, la fonction CU est distante,
    2. les fonctions RU et DU sont localisées dans le satellite, la fonction CU est co-localisée avec la station terrestre,
  4. « RU+DU+CU onboard » i.e. les fonctions RU, DU et CU sont mises en œuvre par le satellite :
    1. les fonctions RU, DU et CU sont localisées dans le satellite,
    2. les fonctions RU, DU, CU et UPF (en anglais « User Plane Function ») sont localisées dans le satellite.
Plus généralement, tout ou partie des fonctions virtualisées (RU, DU, CU) du RAN satellitaire peuvent être réparties sur un ou plusieurs satellites d’une constellation et une ou plusieurs stations terrestres. Comparé à un réseau d’accès radio RAN terrestre, le RAN satellitaire implique au moins une connexion radio supplémentaire, par exemple de type e-CPRI, afin de relier le satellite à la station terrestre puis au cœur de réseau mobile, voire plus lorsque les fonctions virtualisées sont réparties sur plusieurs satellites, avec l’usage de liens ISL (pour « Inter Satellite Link », en anglais) entre satellites.
Quelle que soit la configuration choisie, la distance entre ces fonctions virtualisées (et par conséquence la latence) doit être minimisée pour tenir les délais établis pour la 5G. Notamment, la latence entre la fonction RU et la fonction DU doit être inférieure à une milliseconde. Autrement dit, lorsque la fonction DU est elle aussi localisée dans l’espace (comme la fonction RU), le système est moins sensible à la latence entre le satellite et la station terrestre au moins en ce qui concerne le traitement radio mobile.
De même, la fonction CU peut aussi être placée dans la constellation de satellites, dans la station terrestre ou même dans un équipement d’un centre de données (pour « data center », en anglais) distant.
On note par ailleurs que la capacité d’un satellite à émuler une cellule 5G terrestre est limitée. En effet, du fait de la distance entre le satellite et l’équipement utilisateur (par exemple 500 km pour un RAN satellitaire au lieu de 5km pour un RAN terrestre) et/ou de l’angle du faisceau radio émulant la cellule radio, la taille de la cellule émulée est très grande (par exemple 50km de diamètre pour une cellule radio RaF émulée par un RAN satellitaire au lieu de 5km de diamètre pour une cellule terrestre associée à une antenne terrestre).
Or certaines applications, par exemple les applications Web commerciales, nécessitent de télécharger et traiter un volume important de données à l’initialisation de la connexion entre l’équipement utilisateur et le serveur de données. De la même façon, l’échange de certificats (par exemple lors des « handshake » des protocoles TLS ou QUIC) nécessite un débit important lors de l’initialisation de la connexion.
Il existe donc un besoin pour fournir un débit minimum aux équipements utilisateurs en début de connexion, notamment lorsqu’ils sont présents dans une cellule émulée par un RAN satellitaire, ou plus généralement émulée par un équipement intermédiaire mobile (i.e. distinct d’une station fixe terrestre) entre l’équipement utilisateur et un serveur de données.
3. Exposé de l’invention
L’invention propose une solution ne présentant pas l’ensemble des inconvénients de l’art antérieur, sous la forme d’un procédé de gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement intermédiaire mobile générant au moins un faisceau radio couvrant une zone géographique terrestre, dite cellule radio.
Selon l’invention, un tel procédé met en œuvre les étapes suivantes, pour un flux de données dudit au moins un faisceau radio :
  • obtention du nombre de phases individuelles, associées chacune à un débit cible dans ledit flux, pour des transmissions dudit équipement intermédiaire mobile vers ladite cellule radio,
  • détection d’un début de connexion d’un premier équipement utilisateur, présent dans ladite cellule radio, avec un premier serveur de données, via ledit équipement intermédiaire mobile,
  • si une phase individuelle est disponible pour ledit flux : transmission de données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, au débit cible de la phase individuelle, jusqu’à un critère d’arrêt,
  • si aucune phase individuelle n’est disponible pour ledit flux : transmission de données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, à un débit inférieur audit débit cible.
Par phase individuelle, on entend ici un ensemble de ressources radio du flux de données du faisceau radio, utilisé pour les transmissions entre l’équipement intermédiaire mobile et la cellule radio, permettant d’atteindre un débit cible. Plus généralement, si le flux dispose de N phases individuelles (
Figure pctxmlib-appb-M000001
), cela signifie qu’il dispose de ressources radio disponibles pour les transmissions entre l’équipement intermédiaire mobile et la cellule radio permettant d’atteindre N débits cibles. Par exemple, deux utilisateurs présents dans la cellule radio peuvent recevoir simultanément le flux de données portant d’une part des données de début de connexion à un premier débit cible en provenance du premier serveur de données, et d’autre part des données de début de connexion à un deuxième débit cible en provenance d’un deuxième serveur de données. Les débits cibles peuvent être différents.
L’invention propose ainsi d’estimer la capacité d’une cellule radio émulée par un faisceau radio, i.e. le nombre d’équipements utilisateurs pouvant simultanément recevoir des données avec un débit cible, correspondant au nombre de phases individuelles du flux de données. De cette façon, à chaque nouvelle connexion d’un équipement utilisateur, il est possible de vérifier si une phase individuelle est disponible, et si tel est le cas, de transmettre les données de début de connexion sur la phase individuelle du flux, i.e. avec le débit cible de la phase individuelle.
La solution proposée permet ainsi, selon au moins un mode de réalisation, d’améliorer la qualité de l’expérience utilisateur en accélérant le début des connexions.
Le reste de la bande passante radio, non utilisé par la ou les phases individuelles, peut être utilisé par les connexions des autres équipements utilisateurs, notamment pour la transmission de données de « poursuite » de connexion.
La solution proposée permet ainsi, selon au moins un mode de réalisation, d’utiliser de façon efficace l’ensemble de la bande passante radio.
Par exemple, lorsqu’un équipement utilisateur se connecte à une application Web, il est possible de fournir dès le début de la connexion un débit cible
Figure pctxmlib-appb-M000002
 d’environ 8 Mbps (soit un volume
Figure pctxmlib-appb-M000003
 de 2 Mega octets de données durant une durée
Figure pctxmlib-appb-M000004
de 2 secondes) afin de supporter des interactions à un rythme suffisamment élevé pour maintenir l’attention et la confiance des utilisateurs.
Pour la suite de la connexion, le débit nécessaire dépend des usages et de l’activité de l’utilisateur. Il est souvent moindre compte tenu de la réutilisation des données téléchargées au début de connexions par l’application Web (CSS, librairies javascript, images en cache…), et du temps de traitement des données (par exemple la concentration de l’attention de l’utilisateur sur la page en cours). Ainsi, la transmission des données entre l’équipement intermédiaire mobile et l’équipement utilisateur peut s’effectuer au débit cible de la phase individuelle jusqu’à un critère d’arrêt, puis à un débit inférieur au débit cible.
En particulier, ces différentes étapes peuvent être mises en œuvre par un même équipement (par exemple un équipement géré par l’opérateur de l’équipement intermédiaire ou un équipement géré par l’opérateur de l’équipement utilisateur). En variante, du fait de la virtualisation de certaines fonctions, ces étapes peuvent être mises en œuvre par différents équipements (par exemple les étapes d’obtention du nombre de phases individuelles et de détection d’un début de connexion peuvent être mises en œuvre par au moins un équipement géré par l’opérateur de l’équipement utilisateur, et les étapes de transmission par au moins un équipement géré par l’opérateur de l’équipement intermédiaire).
Selon un mode de réalisation particulier, le nombre de phases individuelles du flux du faisceau radio est défini à partir d’au moins un paramètre appartenant au groupe comprenant :
  • ledit débit cible
    Figure pctxmlib-appb-M000005
    ,
  • une puissance d’émission
    Figure pctxmlib-appb-M000006
     dudit équipement intermédiaire mobile,
  • un facteur de propagation
    Figure pctxmlib-appb-M000007
     entre ledit équipement intermédiaire mobile et ladite cellule radio, ou au moins un équipement utilisateur présent dans ladite cellule radio,
  • une bande passante
    Figure pctxmlib-appb-M000008
    dudit équipement intermédiaire mobile,
  • un angle d’ouverture de l’antenne d’émission
    Figure pctxmlib-appb-M000009
     dudit équipement intermédiaire mobile,
  • une distance
    Figure pctxmlib-appb-M000010
     entre ledit équipement intermédiaire mobile et ladite cellule radio, ou au moins un équipement utilisateur présent dans ladite cellule radio,
  • un nombre de faisceaux radio interférents
    Figure pctxmlib-appb-M000011
     entre ledit équipement intermédiaire mobile et au moins une autre cellule radio,
  • un bruit thermique
    Figure pctxmlib-appb-M000012
    ,
  • la variance, ou écart-type, de l’effet de masque (en anglais « shadowing »)
    Figure pctxmlib-appb-M000013
    ,
  • une probabilité de non-couverture
    Figure pctxmlib-appb-M000014
    .
La capacité d’une cellule radio dépend donc des caractéristiques du faisceau radio généré par l’équipement intermédiaire.
En particulier, un tel équipement intermédiaire est mobile, i.e. distinct d’une station terrestre fixe. Il s’agit par exemple d’un équipement terrestre ou d’un équipement non-terrestre, comme un satellite, un avion, un ballon, un drone, une HIBS etc.
Un tel équipement intermédiaire est également appelé équipement d’accès, en ce qu’il peut se connecter directement à un équipement utilisateur (i.e. sans passage par une antenne terrestre fixe).
Selon un mode de réalisation particulier, le nombre de phases individuelles du flux est égal à la partie entière de la capacité
Figure pctxmlib-appb-M000015
 du faisceau radio généré par l’équipement intermédiaire mobile :
Figure pctxmlib-appb-M000016
)
avec :
Figure pctxmlib-appb-M000017
Figure pctxmlib-appb-M000018
  • Figure pctxmlib-appb-M000019
    ).
La partie décimale de la capacité
Figure pctxmlib-appb-M000020
 correspond au débit restant pour les transmissions en dehors de la ou des phases individuelles, dites de « poursuite ».
La solution proposée selon ce mode de réalisation permet ainsi de déterminer simplement la répartition des ressources radio du flux, entre la ou les phases individuelles et le reste du flux. La répartition selon ce mode de réalisation se fait par une division entière et un modulo.
Par exemple, le critère d’arrêt d’une transmission au débit cible d’une phase individuelle appartient au groupe comprenant :
  • une période donnée
    Figure pctxmlib-appb-M000021
     (par exemple de l’ordre de 2 à 4 secondes),
  • un volume donné
    Figure pctxmlib-appb-M000022
     (par exemple de l’ordre de 2 à 4 méga-octets),
  • une fin de connexion dudit premier équipement utilisateur avec ledit premier serveur de données,
  • une détection d’un début de connexion d’un deuxième équipement utilisateur, présent dans ladite cellule radio, à un deuxième serveur de données prioritaire par rapport audit premier serveur de données.
Ainsi, il est possible de libérer une phase individuelle du flux après le début de la connexion, puisque la « poursuite de connexion » nécessite en général un débit inférieur au « début de connexion ». La libération d’une phase individuelle du flux permet à un autre équipement utilisateur de bénéficier du débit cible en début de connexion (ou au premier équipement utilisateur de bénéficier du débit cible en début de connexion pour une nouvelle connexion).
Ainsi, selon la solution proposée, les connexions « établies » (également appelées « poursuite de connexion ») ne capturent pas toute la bande passante radio, et des ressources radio restent disponibles pour de nouvelles connexions.
Ce point est important parce que les contrôles de congestion des connexions de bout en bout deviennent de plus en plus agressifs et préemptent un maximum de bande passante au détriment des nouvelles connexions.
Selon un mode de réalisation particulier, le critère d’arrêt d’une transmission au débit cible d’une phase individuelle dépend d’un type de service ou du domaine demandé.
Ainsi, si le service ou le domaine demandé est de type vidéo par exemple, le temps alloué pour la phase individuelle peut être plus long, par exemple de l’ordre de 4 à 10 secondes, ou le volume de données alloué pour la phase individuelle peut être supérieur, par exemple de l’ordre de 4 à 10 mégaoctets.
Il est également possible de libérer une phase individuelle du flux si un équipement utilisateur souhaite établir une connexion avec un service d’urgence.
Selon un mode de réalisation particulier, l’étape d’obtention du nombre de phases individuelles est mise à jour :
  • périodiquement, ou
  • suite à une modification d’un paramètre dudit équipement intermédiaire mobile, ou
  • suite à une modification d’un paramètre du faisceau radio généré par l’équipement intermédiaire mobile, ou
  • suite à une modification dudit critère d’arrêt.
Le nombre de phases individuelles du flux peut ainsi être ajusté dynamiquement, notamment de manière asynchrone. Par exemple, le nombre de phases individuelles peut être augmenté suite à un besoin du cœur de réseau 5G du à une saturation ou un incident sur une cellule terrestre appartenant à la zone géographique terrestre couverte par le faisceau radio .
Selon un mode de réalisation particulier, l’étape de détection d’un début de connexion met en œuvre la détection d’un échange de données de sécurisation de la connexion entre ledit premier équipement utilisateur et ledit premier serveur de données.
Selon un mode de réalisation particulier, la détection d’un début de connexion comprend :
  • l’identification des données de début de connexion, à partir d’au moins un marqueur inséré par un module de type RRC (en anglais « Radio Resource Control ») dans au moins un paquet de données en provenance dudit premier serveur de données,
  • l’insertion des données de début de connexion dans ladite phase individuelle disponible pour ledit flux par un module de type MAC (en anglais « Medium Access Layer »).
Selon ce mode de réalisation, la solution proposée encourage ainsi l’exposition de la signalisation de bout en bout des connexions.
Selon un mode de réalisation particulier, le procédé met en œuvre le stockage d’informations relatives à ladite au moins une phase individuelle dans une table de gestion des phases individuelles.
En particulier, seules les informations relatives à la ou aux phases individuelles sont stockées dans une table. De cette façon, la taille des données stockées est faible.
L’invention concerne également un système de gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement intermédiaire mobile générant au moins un faisceau radio couvrant une zone géographique terrestre, dite cellule radio.
Selon l’invention, un tel équipement comprend, pour un flux de données dudit au moins un faisceau radio :
  • un module d’obtention du nombre de phases individuelles associées chacune à un débit cible dans ledit flux, pour des transmissions dudit équipement intermédiaire mobile vers ladite cellule radio,
  • un module de détection d’un début de connexion d’un premier équipement utilisateur, présent dans ladite cellule radio, avec un premier serveur de données, via ledit équipement intermédiaire mobile,
  • un module de transmission de données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, au débit cible de la phase individuelle, jusqu’à un critère d’arrêt, activés si une phase individuelle est disponible pour ledit flux,
  • un module de transmission de données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, à un débit inférieur audit débit cible, activés si aucune phase individuelle n’est disponible pour ledit flux.
Par exemple, un tel système comprend un ou plusieurs équipements gérés par l’opérateur de l’équipement intermédiaire (par exemple l’opérateur satellite) et/ou l’opérateur de l’équipement utilisateur.
Ces différents modules peuvent notamment être co-localiés ou distants. Par exemple, les modules d’obtention du nombre de phases individuelles et de détection d’un début de connexion appartiennent à au moins un équipement géré par l’opérateur de l’équipement utilisateur, et les modules de transmission appartiennent à au moins un équipement géré par l’opérateur de l’équipement intermédiaire. Selon un autre exemple, certains modules peuvent être localisés sur des satellites différents.
Selon d’autres modes de réalisation, ces différents modules correspondent à des blocs fonctionnels, qui peuvent être co-localisés ou distants.
L’invention concerne encore un ou plusieurs programmes d’ordinateur comportant des instructions pour la mise en œuvre d’un procédé de gestion des communications tel que décrit ci-dessus lorsque ce ou ces programmes sont exécutés par au moins un processeur.
4. Liste des figures
D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante d’un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
- la , introduite dans la partie art antérieur, illustre la virtualisation des fonctions d’un réseau d’accès radio selon la norme 5G ;
- la , également introduite dans la partie art antérieur, illustre les interfaces entre les différentes fonctions virtualisées d’un réseau d’accès radio selon la norme 5G ;
- la , également introduite dans la partie art antérieur, présente un exemple d’architecture de réseau d’accès radio comprenant un satellite ;
- la présente les principales étapes mises en œuvre par le procédé de gestion des communications selon un mode de réalisation particulier de l’invention ;
- la présente les principales étapes mises en œuvre lorsqu’un équipement utilisateur cherche à se connecter à un serveur, via l’équipement intermédiaire mobile ;
- la illustre un exemple d’architecture de réseau d’accès radio comprenant un satellite selon un mode de réalisation de l’invention ;
- la illustre les messages échangés entre les différentes entités du réseau d’accès radio selon la  ;
- la présente la structure simplifiée d’au moins un équipement d’un système de gestion des communications selon un mode de réalisation particulier.
5. Description d’un mode de réalisation particulier
5.1 Principe général
L’invention se place dans le contexte d’un réseau de communication mettant en œuvre un équipement intermédiaire mobile de transmission (i.e. au moins une antenne radio qui se déplace, par exemple un satellite, un avion, un ballon, un drone, une HIBS, etc), et propose une solution pour améliorer les communications via l’équipement intermédiaire mobile de transmission.
Le principe général de l’invention repose sur l’estimation du nombre de phases individuelles disponible dans le flux de données du faisceau radio généré par l’équipement intermédiaire mobile de transmission et émulant une cellule radio, et sur l’allocation d’une phase individuelle en début de connexion (si une phase individuelle est disponible) permettant une transmission des données à un débit souhaité (dit débit cible) en début de connexion. La solution proposée permet ainsi d’accélérer le début des connexions.
La illustre les principales étapes pour la gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement utilisateur et au moins un équipement intermédiaire mobile.
On considère un équipement intermédiaire mobile générant un faisceau radio « éclairant » une cellule radio, également appelée RaF. Le flux de données du faisceau radio émis par l’équipement intermédiaire mobile est reçu par l’ensemble des équipements utilisateurs présents dans la cellule radio. Un tel flux peut donc porter des données destinées aux différents équipements utilisateurs, sous la forme d’un multiplex.
Au cours d’une première étape 41, on obtient le nombre de phases individuelles, associées chacune à un débit cible dans le flux, à servir pour des transmissions de l’équipement intermédiaire mobile vers la cellule radio.
Au cours d’une deuxième étape 42, on détecte qu’un premier équipement utilisateur, présent dans la cellule radio, se connecte avec un premier serveur de données, via l’équipement intermédiaire mobile.
On vérifie alors (43) si une phase individuelle est disponible (i.e. si des ressources radio pour la transmission au débit cible sont disponibles).
Si une phase individuelle est disponible pour le flux (431) : les données de début de connexion en provenance du premier serveur de données peuvent être transmise, entre l’équipement intermédiaire mobile et le premier équipement utilisateur, au débit cible de la phase individuelle, jusqu’à un critère d’arrêt.
Par exemple, le critère d’arrêt appartient au groupe comprenant :
  • une période donnée
    Figure pctxmlib-appb-M000023
    ,
  • un volume donné
    Figure pctxmlib-appb-M000024
    ,
  • une fin de connexion du premier équipement utilisateur avec le premier serveur de données,
  • une détection d’un début de connexion d’un deuxième équipement utilisateur, présent dans la cellule radio, à un deuxième serveur de données prioritaire par rapport audit premier serveur de données,
  • etc.
Si aucune phase individuelle n’est disponible pour le flux (432) : les données de début de connexion en provenance du premier serveur de données peuvent être transmise, entre l’équipement intermédiaire mobile et le premier équipement utilisateur, à un débit inférieur au débit cible de la phase individuelle.
On utilise de cette façon la bande passante radio de façon efficace, en réservant une partie de la bande passante pour les débuts de connexion et le reste de la bande passante pour la poursuite des connexions.
Il est ainsi possible de servir une ou plusieurs connexions à la fois, par exemple à un débit
Figure pctxmlib-appb-M000025
 pour une nouvelle connexion et
Figure pctxmlib-appb-M000026
 pour une poursuite de connexion, en utilisant toute la bande passante radio. Si on considère
Figure pctxmlib-appb-M000027
 ressources radio pour la transmission de données dans le flux du faisceau radio, on a
Figure pctxmlib-appb-M000028
,
avec :
Figure pctxmlib-appb-M000029
 le nombre de phases individuelles,
Figure pctxmlib-appb-M000030
 le nombre de ressources radio permettant d’atteindre un débit cible
Figure pctxmlib-appb-M000031
 (i.e. utilisées pendant la phase individuelle) ;
Figure pctxmlib-appb-M000032
 le nombre de ressources radio restantes.
On note que les différentes étapes présentées ci-dessus peuvent être mises en œuvre par l’équipement intermédiaire mobile ou par un équipement géré par l’opérateur de l’équipement intermédiaire mobile. Toutefois, du fait de la virtualisation de certaines fonctions, certaines étapes pourraient être mises en œuvre par un équipement non mobile, par exemple une station fixe terrestre.
5.2 Description d’un mode de réalisation particulier
On présente ci-après un exemple de mise en œuvre de l’invention.
On considère par exemple que l’équipement intermédiaire mobile est un satellite, géré par un opérateur de réseau satellite SNO. Un tel satellite est appelé satellite d’accès, en ce qu’il peut se connecter directement à un équipement utilisateur.
Le SNO, par exemple l’OSS (« Operations Support System »), configure un RAN satellitaire.
Par exemple, un satellite peut générer un ou plusieurs faisceaux radio, également appelés spots. Les caractéristiques du satellite, ou des faisceaux radio du satellite, peuvent être définis à partir de différents paramètres :
Paramètre Définition
Figure pctxmlib-appb-M000033
 		puissance d’émission du spot
Figure pctxmlib-appb-M000034
 		facteur de propagation qui dépend de la fréquence
Figure pctxmlib-appb-M000035
 		bande passante (MHz) du spot
Figure pctxmlib-appb-M000036
Figure pctxmlib-appb-M000037
, avec
Figure pctxmlib-appb-M000038
 le débit cible (Mbits/s) d’une phase individuelle du flux
Figure pctxmlib-appb-M000039
 		nombre de spots interférents
Figure pctxmlib-appb-M000040
 		écart type du shadowing (dB)
Figure pctxmlib-appb-M000041
,		 bruit thermique au récepteur (constante)
Figure pctxmlib-appb-M000042
 		distance satellite - récepteur
Figure pctxmlib-appb-M000043
 		angle d’ouverture de l’antenne d’émission du spot, typiquement 2 à 5 degrés
Table 1 : Table des caractéristiques (paramètres) des spots
Ces paramètres peuvent être différents pour chaque spot généré par le satellite. En particulier, certains paramètres peuvent être liés aux caractéristiques physiques des équipements (satellite notamment), aux caractéristiques souhaitées par l’opérateur de réseau mobile MNO (par exemple un débit de réception de 5Mbps en début de connexion pour un équipement utilisateur, etc), etc.
Par exemple, les paramètres P de puissance d’émission du spot, W de bande passante du spot peuvent être choisis par le SNO, et le paramètre
Figure pctxmlib-appb-M000044
 correspondant au débit cible d’une phase individuelle peut être choisi par le MNO.
Ainsi, pour chaque spot, l’OSS du SNO collecte les différentes informations d’états du satellite (états principaux et caractéristiques principales de la propagation) et des besoins (venant par exemple par les MNOs) et les stocke dans une table.
Un exemple de table d’états des spots est donné ci-après, pour des satellites en orbite basse à environ 500km :
Spot_ID
Figure pctxmlib-appb-M000045
Figure pctxmlib-appb-M000046
Figure pctxmlib-appb-M000047
Figure pctxmlib-appb-M000048
_UE
Figure pctxmlib-appb-M000049
Figure pctxmlib-appb-M000050
Figure pctxmlib-appb-M000051
1 45 dBm
Figure pctxmlib-appb-M000052
 		10 MHz 5 Mbits/s 6
Figure pctxmlib-appb-M000053
 mW		 500 km
2 50 dBm
Figure pctxmlib-appb-M000054
 		10 MHz 6 Mbits/s 6
Figure pctxmlib-appb-M000055
 mW		 600 km
… 50 dBm
Figure pctxmlib-appb-M000056
 		10 MHz 5 Mbits/s 6
Figure pctxmlib-appb-M000057
 mW		 700 km
1000 55 dBm
Figure pctxmlib-appb-M000058
 		10 MHz 5 Mbits/s 6
Figure pctxmlib-appb-M000059
 mW		 600 km
Table 2 : Table d’états des spots
Cette table peut notamment être échangée entre l’OSS du SNO et le satellite.
Le nombre de phases individuelles d’un flux de données d’un spot peut être déterminé à partir d’un ou plusieurs paramètres définis dans les tables ci-dessus.
Par exemple, le nombre de phases individuelles du flux est égal à la partie entière de la capacité
Figure pctxmlib-appb-M000060
 du faisceau radio, telle que :
Figure pctxmlib-appb-M000061
) (1)
avec :
  • Figure pctxmlib-appb-M000062
     (2)
  • Figure pctxmlib-appb-M000063
     (3)
  • Figure pctxmlib-appb-M000064
    ) (4) et
  • Figure pctxmlib-appb-M000065
    .
En d’autres termes, considérant un utilisateur utilisant un service donné avec une contrainte de débit minimum
Figure pctxmlib-appb-M000066
 (débit cible), et utilisant une bande passante W, la solution proposée permet d’établir la capacité d’un spot à l’aide de l’expression (1) ci-dessus.
Cette capacité caractérise le nombre d’équipements utilisateurs
Figure pctxmlib-appb-M000067
recevant simultanément des données avec le débit cible
Figure pctxmlib-appb-M000068
. Autrement dit, cette expression répond aux contraintes en termes de débit minimum à atteindre par chaque équipement utilisateur.
La capacité
Figure pctxmlib-appb-M000069
 du faisceau radio, à un instant donné, tient notamment compte :
  • de la valeur moyenne m de la puissance reçue par l’équipement utilisateur,
  • des contraintes liées à l’environnement de l’équipement utilisateur au sol, caractérisées par l’écart type
    Figure pctxmlib-appb-M000070
     due au shadowing, au niveau du récepteur connecté à un spot donné. On note que la valeur de ce dernier paramètre peut être fournie par le MNO pour chaque RAN émulé,
  • de la probabilité de non-couverture
    Figure pctxmlib-appb-M000071
    , ou probabilité « d’outage ». Il s’agit de la probabilité qu’il n’y ait pas suffisamment de ressources radio pour une transmission au débit cible au moment où l’équipement utilisateur se connecte. En d’autres termes, l’équipement utilisateur a une probabilité
    Figure pctxmlib-appb-M000072
     de ne pas pouvoir se connecter au spot avec le débit cible
    Figure pctxmlib-appb-M000073
    . Cette valeur peut également être choisie par le MNO.
En effet, comme le spot doit fournir un service sur une zone donnée, avec une probabilité de non couverture Pout garantie par l’opérateur, ces contraintes ont un impact sur la détermination de la capacité du spot.
La capacité
Figure pctxmlib-appb-M000074
 peut également s’exprimer sous la forme suivante :
Figure pctxmlib-appb-M000075
On obtient ainsi le nombre de connexions
Figure pctxmlib-appb-M000076
 (i.e. de phases individuelles de flux) pouvant recevoir le débit cible
Figure pctxmlib-appb-M000077
 sous contrainte de
Figure pctxmlib-appb-M000078
pendant une durée donnée.
La partie décimale de la capacité
Figure pctxmlib-appb-M000079
 correspond au débit restant pour les transmissions en dehors de la ou des phases individuelles.
Les paramètres, notamment la probabilité de non-couverture
Figure pctxmlib-appb-M000080
, peuvent être ajustés pour augmenter le nombre de phases individuelles
Figure pctxmlib-appb-M000081
 quand nécessaire. La probabilité de non-couverture
Figure pctxmlib-appb-M000082
 peut notamment être choisie parmi une liste de valeurs possibles (
Figure pctxmlib-appb-M000083
Figure pctxmlib-appb-M000084
; etc). Ces différentes informations peuvent être ajoutées dans la table d’états des spots.
Spot_ID
Figure pctxmlib-appb-M000085
Figure pctxmlib-appb-M000086
 		Commentaire
1
Figure pctxmlib-appb-M000087
;
Figure pctxmlib-appb-M000088
 		2
Figure pctxmlib-appb-M000089
 appartenant à un intervalle permettant d’obtenir si possible 2 phases individuelles
2
Figure pctxmlib-appb-M000090
;
Figure pctxmlib-appb-M000091
 		1
Figure pctxmlib-appb-M000092
 appartenant à un intervalle permettant d’obtenir une seule phase individuelle
…
Figure pctxmlib-appb-M000093
1000
Figure pctxmlib-appb-M000094
;
Figure pctxmlib-appb-M000095
On distingue ainsi plusieurs phases dans le flux du faisceau radio ainsi généré : au moins une phase individuelle, notée DebCo, servant les données du début de chaque connexion, et une phase dite « commune », notée ContCo, regroupant les données suivantes des connexions existantes.
Comme indiqué précédemment, ces différentes phases permettent notamment d’utiliser efficacement la bande passante radio et d’améliorer la qualité de l’expérience utilisateur.
En particulier, le nombre de phases individuelles peut être mis à jour :
  • périodiquement, ou
  • suite à une modification d’un paramètre de l’équipement intermédiaire mobile, ou
  • suite à une modification d’un paramètre du faisceau radio généré par l’équipement intermédiaire mobile, ou
  • suite à une modification d’un critère d’arrêt,
  • etc.
Par exemple, périodiquement ou de manière asynchrone (sur évènement, par exemple, suite à un besoin du cœur 5G du une saturation ou un incident sur un RAN terrestre), l’OSS du MNO estime le nombre de nouvelles connexions à servir par le RAN satellitaire, puis détermine ou met à jour les différents paramètres à partir de l’expression (1) ci-dessus et de la table courante des états des spots, notamment :
  • les phases individuelles en cours d’utilisation dans les connexions (i.e. le nombre de connexions recevant le débit cible),
  • le nombre de nouvelles connexions pouvant recevoir le débit cible
    Figure pctxmlib-appb-M000096
     sous contrainte de
    Figure pctxmlib-appb-M000097
    pendant une durée donnée, correspondant à
    Figure pctxmlib-appb-M000098
    ,
  • le débit individuel
    Figure pctxmlib-appb-M000099
    , en Mbps, par exemple 5 Mbps,
  • la durée
    Figure pctxmlib-appb-M000100
     du débit individuel (i.e. la durée d’une phase individuelle), en seconde, par exemple 3 s,
  • ou le volume individuel
    Figure pctxmlib-appb-M000101
     (i.e. le volume de données transmis dans une phase individuelle), en Mo, par exemple 2,5 Mo,
  • la probabilité de non-couverture
    Figure pctxmlib-appb-M000102
    .
Ces différents paramètres peuvent également être ajoutés dans la table d’états des spots.
En particulier, les valeurs de
Figure pctxmlib-appb-M000103
,
Figure pctxmlib-appb-M000104
,
Figure pctxmlib-appb-M000105
 et
Figure pctxmlib-appb-M000106
 peuvent être ajustées dynamiquement pour optimiser le multiplexage statistique.
Ces paramètres peuvent notamment être choisis en fonction du service ou du domaine du serveur demandé. Par exemple, une connexion vers un domaine video.example.com peut obtenir au démarrage le double de temps
Figure pctxmlib-appb-M000107
 ou de mega octets
Figure pctxmlib-appb-M000108
 par rapport à des valeurs par défaut.
L’OSS du MNO ou du SNO peut notamment mettre à jour ces paramètres pour les connexions existantes en cours. Par exemple, si un équipement utilisateur se connecte à un service d’urgence, l’OSS peut raccourcir (au moins temporairement) la durée
Figure pctxmlib-appb-M000109
 d’une phase individuelle d’une connexion existante, pour libérer la phase individuelle de la connexion existante. De cette façon, le satellite peut récupérer la phase individuelle pour le début de connexion de l’équipement utilisateur avec le service d’urgence.
L’OSS du SNO peut notamment communiquer cette table d’états des spots au satellite.
On décrit ci-après, en relation avec la , les différentes étapes mises en œuvre lorsqu’un équipement utilisateur cherche à se connecter à un serveur, via l’équipement intermédiaire mobile. Ces différentes étapes permettent de générer, en sortie du satellite, un flux de données distribué sur l’ensemble de la cellule radio.
Au cours d’une première étape 51, un module RRC cherche à détecter les nouvelles connexions dans le flux des paquets IP reçus en entrée du satellite, à partir de la signalisation de début de connexion, de la taille, de l’encodage, de la signature temporelle des paquets, des champs des entêtes des paquets IP identifiant le flux IP (adresse source, adresse destination, protocole, port source, port destination, etc). En variante, une telle étape peut être mise en œuvre par un module RLC (en anglais « Radio Link Control »), voire MAC.
On considère par exemple qu’un équipement utilisateur présent dans la cellule radio cherche à se connecter à un site internet monexemple.com, hébergé sur un serveur de données. Une phase de négociation est classiquement mise en œuvre entre l’équipement utilisateur et le serveur de données, via le satellite si l’on considère un RAN satellitaire.
Par exemple, lors de l’établissement d’une connexion HTTPS, un processus de type « Handshake TLS » est mis en œuvre entre l’équipement utilisateur et le serveur de données, via le satellite. Ce processus inclut une phase non chiffrée lors du téléchargement des certificats. Le module RRC peut ainsi détecter les différentes phases des connexions sécurisées des protocoles QUIC, TLS, DTLS, EDHOC et similaires, et détecter le début d’une connexion internet.
Si l’on considère le protocole QUIC, le module RRC peut identifier à partir de la taille, de l’encodage, et/ou de la présence d’un message de type « ClientHello » les phases transportant les certificats correspondant à une première connexion (QUIC 1-RTT), des phases de reconnexion avec reprise de sessions (reprise du contexte de la connexion précédente, dite QUIC 0-RTT crypto).
Le module RRC peut ainsi détecter le début d’une nouvelle connexion.
Le module RRC peut également classer les paquets reçus (comme étant à transmettre sur une phase individuelle ou sur une phase commune) à partir de la signalisation de début de connexion, de la taille, de l’encodage, de la signature temporelle des paquets …
Si l’on considère le protocole QUIC ou TLS, le module RRC peut identifier à partir de la présence d’un message de type « ClientHello » les phases transportant les certificats correspondant à une première connexion (QUIC 1-RTT), des phases de reconnexion avec reprise de sessions (reprise du contexte de la connexion précédente, dite QUIC 0-RTT crypto) et classer les phases 1-RTT pour les transmettre sur une phase individuelle et les phases 0-RTT pour les transmettre sur une phase commune.
Optionnellement, pour éviter qu’un équipement utilisateur se connecte de multiples fois avec le même serveur pour bénéficier à chaque fois de la phase individuelle qui permet d’atteindre un débit cible (i.e. « charding » consistant à créer plus de connexion pour capturer plus de bande passante), une connexion peut être identifiée au niveau 3 (adresse source, adresse destination, protocole, port source, port destination, etc).
A détection d’un début de connexion, le module RRC peut transmettre un indicateur de début de connexion DebCoFlag au module RLC au cours d’une étape 521, ou directement au module MAC au cours d’une étape 522.
Selon un premier exemple, un tel indicateur de début de connexion peut être destiné au module RLC. Ainsi, un tel indicateur de début de connexion peut être inséré dans un entête propriétaire ou à la place d’un bit inutilisé, par exemple un bit réservé du protocole QUIC, par exemple le « spin bit ». Afin de permettre une interopérabilité, un tel indicateur de début de connexion peut en variante être inséré dans un message non propriétaire, par exemple l’entête iOAM (« In-situ OAM), un message ECN (« Explicit Congestion Notification »), etc.
Selon un deuxième exemple, un tel indicateur de début de connexion est directement envoyé au module MAC.
La détection d’un tel indicateur de début de connexion permet d’identifier les paquets des flux IP reçus par le satellite qui doivent être transmis dans la ou les phases individuelles en sortie du satellite.
Éventuellement, un indicateur de fin de connexion FinCoFlag peut être transmis au module RLC ou au module MAC. En variante, une information de durée DebCoDuration ou de volume DebCoVol peut être transmise au module RLC ou au module MAC. Il est ainsi possible de marquer tous les paquets successifs comme étant à transmettre sur une phase individuelle, ou uniquement le premier et le dernier paquet concernés.
Encore en variante, l’indicateur de début de connexion DebCoFlag peut être un entier correspondant à DebCoDuration ou à DebCoVol.
Cet indicateur de fin de connexion FinCoFlag, ou ces informations DebCoDuration ou DebCoVol, peuvent être utilisées pour déterminer quand arrêter la transmission dans la ou les phases individuelles en sortie du satellite.
Selon le premier exemple présenté ci-dessus (indicateur de début de connexion destiné au module RLC), si le module RLC reçoit un indicateur de début de connexion DebCoFlag, il peut l’ajouter (54) dans les premières trames (ou « subframes ») destinées au module MAC, puis transmettre les premières trames avec l’indicateur de début de connexion DebCoFlag.
Si l’indicateur de début de connexion DebCoFlag est un entier correspondant à la durée DebCoDuration, il peut être décrémenté avec le temps (par exemple, si DebCoDuration est égal à 5 secondes, la première trame porte l’indicateur 5, la deuxième trame porte l’indicateur 4, …, la cinquième trame porte l’indicateur 1 et la sixième trame ne porte pas d’indicateur).
Si l’indicateur de début de connexion DebCoFlag est un entier correspondant au volume DebCoVol, il peut être décrémenté en tenant compte de la taille de chaque trame.
Passé ce délai DebCoDuration, ou une fois atteint ce volume DebCoVol, ou à détection d’un indicateur de type fin de connexion FinCoFlag, le module RLC ne marque plus les trames (i.e. n’insère plus d’indicateur dans les trames).
Selon un mode de réalisation particulier, en l’absence de ressource radio, le module RLC ne transmet pas au module MAC les trames non marquées. En variante, selon le type du module RLC (par exemple « Transparent Mode (TM) », « Unacknowledged Mode (UM) » ou « Acknowledged Mode (AM) », tel que défini par exemple dans la spécification technique 3GPP TS 38.322 version 15.3.0 Release 15), le module RLC ne transmet pas au module MAC les trames non marquées. Ces trames sont considérées comme jetées ou « poubellisées ».
Par ailleurs, si le module RLC ne reçoit pas d’indicateur de début de connexion DebCoFlag, il peut directement transmettre les premières trames au module MAC, sans les marquer.
A réception des trames marquées selon le premier exemple présenté ci-dessus (indicateur de début de connexion destiné au module RLC), le module MAC détecte l’indicateur de début de connexion inséré dans les trames par le module RLC, et émet (55) les trames dans la phase individuelle du flux de données.
Par exemple, le module MAC identifie les données de début de connexion à partir d’au moins un marqueur/indicateur inséré par le module RRC dans au moins un paquet de données en provenance du premier serveur de données (premières trames). Le module MAC peut ainsi insérer les données de début de connexion dans la phase individuelle du flux du faisceau radio.
Si le module MAC reçoit d’une part des trames non marquées du module RLC et d’autre part l’indicateur de début de connexion en provenance du module RRC selon le deuxième exemple présenté ci-dessus (indicateur de début de connexion destiné directement au module MAC), il peut directement émettre (55) les trames identifiées à partir de l’indicateur de début de connexion dans la phase individuelle du flux de données.
Le module MAC peut émettre les trames restantes dans la phase commune (i.e. avec un débit inférieur au débit cible) s’il lui reste des ressources.
Selon un mode de réalisation particulier, en l’absence de ressource radio, le module MAC ne transmet pas les trames restantes. Ces trames sont considérées comme jetées ou « poubellisées ».
Dans le mode de réalisation décrit ci-dessus, on suppose que les modules RRC, RLC et MAC sont co-localisés dans le satellite. En variante, le module RRC et/ou le module RLC peuvent être distants, et notamment localisés dans un équipement terrestre fixe.
A titre d’exemple, on détaille ci-après en relation avec les figures 6 et 7 la génération d’un RAN satellitaire et la mise en œuvre de la solution proposée pour fournir un débit minimum aux services d’urgences par exemple.
Par exemple, des RAN satellitaires peuvent être déployés pour compléter ou remplacer les RAN terrestres :
  • la nuit ou en heure creuse pour arrêter les antennes terrestres et diminuer la puissance consommée et les radiations émises ;
  • en cas de panne d’un RAN terrestre ;
  • pour délester un RAN terrestre aux heures de pointe ;
  • pour effectuer la maintenance d’un RAN terrestre ;
  • etc.
L’exemple ci-dessous développe le cas de la maintenance d’un RAN terrestre d’un MNO. Un exemple d’usage du procédé par un MNO consiste à utiliser la capacité d’un RAN satellitaire lors d’une opération de maintenance planifiée d’un RAN terrestre (par exemple changement de carte, redémarrage…). Cette opération peut être réalisée la nuit en heure creuse. Le RAN satellitaire doit avoir une capacité minimale suffisante pour remplacer le RAN terrestre, notamment pour fournir du débit aux services d’urgences.
On se place dans le contexte du réseau de la , selon lequel un satellite SAT génère un faisceau radio 61 émulant une cellule radio (RaF), dans laquelle trois équipements utilisateurs UE1, UE2 et UE3 sont présents.
Le satellite SAT est connecté au réseau terrestre 62 (comprenant l’opérateur du réseau satellite SNO et l’opérateur du réseau mobile MNO) par l’intermédiaire d’une passerelle terrestre GW. Les équipements utilisateurs UE1, UE2 et UE3 peuvent se connecter à l’un ou l’autre des serveurs S1, S2 et/ou S3 via le satellite SAT.
La illustre les messages échangés entre les différentes entités, selon un mode de réalisation de l’invention.
Au cours d’une première étape 71, l’OSS du SNO configure le satellite SAT. Par exemple, l’OSS du MNO transmet des messages de type « bootstrapping » et configuration aux différents modules du satellite SAT (RRC, RLC et MAC notamment).
A titre d’exemple, on considère que le MNO souhaite effectuer la maintenance d’un RAN dont la cellule est à la position géographique Pgeo. Le cœur 5G de ce MNO demande la création d’un RaF RaF1 (61) dont les caractéristiques sont décrites par une entrée d’une table d’états des spots, telle que la table 2 présentée ci-dessus.
On considère par exemple que le nombre de phases individuelles du flux de données du spot est égal à 1. Le RaF RaF1 implémente donc une unique phase individuelle associée à un débit cible. Le débit inutilisé par la phase individuelle du flux de données est utilisé par une phase dite commune.
Le SNO peut ainsi générer le RaF1 dans le satellite avec ces valeurs.
Le SNO peut également créer une table de gestion des phases individuelles, permettant de suivre la ou les phases individuelles du flux de données du faisceau radio du RaF1. Une telle table de gestion peut également être prévue dans la table d’états des spots.
Au cours d’une étape suivante 72, dite « boucle de contrôle », le MNO collecte les différentes informations d’états du satellite et des besoins (par exemple
Figure pctxmlib-appb-M000110
,
Figure pctxmlib-appb-M000111
,
Figure pctxmlib-appb-M000112
,
Figure pctxmlib-appb-M000113
, etc) et les transmet au SNO. Le SNO peut notamment déterminer la capacité du Raf Raf1 à partir de ces informations.
Par exemple, l’OSS/BSS du cœur de réseau 5G (MNO) estime le nombre de nouvelles connections à servir par le RAN satellitaire puis à l’aide du traitement analytique de calcul de la capacité présenté ci-dessus, et de la table d’état des spots du satellite et/ou de la table de gestion des phases individuelles (l’informant notamment du nombre de phases individuelles en cours d’utilisation), il met à jour :
  • le nombre de nouvelles connexions pouvant recevoir le débit cible
    Figure pctxmlib-appb-M000114
     (i.e. le nombre de connexions disposant d’une phase individuelle DebCo, correspondant à
    Figure pctxmlib-appb-M000115
    ) ;
  • le débit individuel
    Figure pctxmlib-appb-M000116
    , en Mbps, par exemple 5 Mbps ;
  • la durée
    Figure pctxmlib-appb-M000117
     du débit individuel, en seconde, par exemple 3 s ;
  • ou le volume individuel
    Figure pctxmlib-appb-M000118
    , en Mo, par exemple 2,5 Mo ;
  • la probabilité de non-couverture
    Figure pctxmlib-appb-M000119
    .
Le MNO peut également compléter et/ou mettre à jour la table de gestion des phases individuelles avec ces différentes valeurs.
On note que les valeurs de
Figure pctxmlib-appb-M000120
,
Figure pctxmlib-appb-M000121
,
Figure pctxmlib-appb-M000122
 et
Figure pctxmlib-appb-M000123
 peuvent être ajustées dynamiquement pour optimiser le multiplexage statistique. Il s’agit d’une plage d’ajustement de chaque paramètre par rapport à la valeur nominale. Par exemple, l’étape d’estimation du nombre de nouvelles connexions à servir par le RAN satellitaire génère cinq scenarii à l’aide du traitement analytique en jouant sur les valeurs de
Figure pctxmlib-appb-M000124
,
Figure pctxmlib-appb-M000125
,
Figure pctxmlib-appb-M000126
 et
Figure pctxmlib-appb-M000127
 en faisant varier leurs valeurs, par exemple de 1 à 5% par pas de 1%. Par exemple, il est possible d’augmenter
Figure pctxmlib-appb-M000128
, pour tendre vers une valeur de
Figure pctxmlib-appb-M000129
 de 2. L’algorithme peut chercher à se rapprocher de la valeur sans chercher à l’atteindre.
Le satellite et le SNO peuvent mettre à jour la table d’états / table de gestion du spot avec ces différentes valeurs (73).
La table de gestion des phases individuelles contient notamment les informations de contrôle de la ou des phases individuelles. Elle est utilisée pour échanger à la fois les informations de contrôle et les instances des phases individuelles.
Un exemple de table est présenté ci-après.
La première ligne de valeurs indique les paramètres de contrôle d’une phase individuelle. Les lignes suivantes décrivent l’avancement des phases individuelles.
Flux Raf1 Nombre de phases individuelles libres (ou type de l’instance) Nombre total de phases individuelles
Figure pctxmlib-appb-M000130
 (ou utilisé par une instance)
Figure pctxmlib-appb-M000131
 (Mbps)
Figure pctxmlib-appb-M000132
 (s)
Figure pctxmlib-appb-M000133
 (Mo)
Contrôle 1 1 5 3 3
Table 3 : Table de gestion des phases individuelles
A ce stade la table de gestion de la phase individuelle est vide.
On note qu’une telle table de gestion des phases individuelles ne contient pas nécessairement d’information sur la phase commune. De cette façon, la taille de la table de gestion reste faible, et sa transmission reste peu coûteuse. Toutefois, afin de faciliter la compréhension de l’invention, les informations sur la phase commune sont précisées dans la table dans la suite de la description.
Par la suite, afin de montrer le fonctionnement du procédé, on considère que trois équipements utilisateurs (UE1, UE2 et UE3, tels qu’illustrés en ) se connectent sur le RaF1. Comme détaillé ci-après, suivant l’espacement temporel de leur connexion, ils disposent ou non d’une phase individuelle. Ainsi, comme illustré en , l’équipement utilisateur UE1 dispose de la phase individuelle du flux pendant une durée Ti_1, et l’équipement utilisateur UE3 dispose de la phase individuelle du flux pendant une durée Ti_3, qui ne chevauche pas Ti_1. En revanche, l’équipement utilisateur UE2 ne dispose pas de la phase individuelle.
Plus précisément, au cours d’une étape 74, l’équipement utilisateur UE1 souhaite établir une connexion avec le serveur S1. Par exemple, l’UE1 envoie un message de type « ClientHello » CHO (« Connexion UE1.Cnx1 end to end starts : ClientHello 1 RTT phase ») au serveur S1, et le serveur répond par un message de type « ServerHello » SHO (« Connexion UE1.Cnx1 end to end signalling : ServerHello »).
Comme indiqué précédemment, le module RRC peut notamment identifier les différentes phases des connexions sécurisées des protocoles QUIC, TLS, DTLS, EDHOC et similaires, en détectant la présence de la signalisation initiale (« handshake »). En particulier, le handshake TLS d’une connexion HTTPS (idem pour QUIC et DTLS et EDHOC) inclut une partie non chiffrée dans le message « ClientHello », notamment la phase dite 1-RTT qui inclut le téléchargement des certificats. Pour QUIC et TLS, le module RRC distingue à partir de la présence du message « ClientHello » les phases transportant les certificats (phase QUIC 1-RTT) des phases de reconnexion avec reprise de sessions (reprise du contexte crypto, dite 0-RTT, de la connexion précédente).
Le module RRC peut donc détecter une nouvelle connexion UE1.CNX1 dans le ou les flux IP reçus par le satellite.
L’OSS du SNO ou le satellite vérifie si une phase individuelle est libre pour la transmission de données de début de connexion du satellite vers l’équipement utilisateur UE1 en consultant la table de gestion des phases individuelles du spot.
Comme le nombre de phases individuelles libre est égal à 1 (cf table 3), cela signifie qu’une phase individuelle est disponible pour le flux quand le début de la connexion UE1.CNX1 est détecté. Il est donc possible de transmettre les données de début de connexion en provenance du serveur de données S1, entre le satellite SAT et l’équipement utilisateur UE1, au débit cible de la phase individuelle (Di_1 = 5 Mbps), jusqu’à un critère d’arrêt (par exemple pendant une durée Ti_1 = 3 s).
Flux Raf1 Nombre de phases individuelles libres ou type de l’instance Nombre total de phases individuelles
Figure pctxmlib-appb-M000134
 (ou utilisé par une instance)
Figure pctxmlib-appb-M000135
 (Mbps)
Figure pctxmlib-appb-M000136
 (s)
Figure pctxmlib-appb-M000137
 (Mo)
Contrôle 0 1 5 3 3
UE1.CNX1 Individuel 1 5 3 3
Table 4 : Table de gestion des phases individuelles
(t = 0 s après le début de la connexion UE1.CNX1)
On suppose que l’équipement utilisateur UE2 souhaite établir une connexion avec le serveur S1 ou le serveur S2. Par exemple, l’UE2 envoie un message de type « ClientHello » au serveur S2.
Le module RRC détecte cette nouvelle connexion UE2.CNX1 dans les flux IP reçu par le satellite, par exemple une seconde après le début de la connexion UE1.CNX1.
L’OSS du SNO ou le satellite vérifie si une phase individuelle est libre pour la transmission de données de début de connexion du satellite vers l’équipement utilisateur UE2 en consultant la table de gestion des phases individuelles du spot.
Comme le nombre de phases individuelles libre est égal à 0 (cf table 4), cela signifie qu’aucune phase individuelle n’est disponible pour le flux. Les données de début de connexion en provenance du serveur S2 sont donc transmises du satellite SAT vers l’équipement utilisateur UE2 à un débit inférieur au débit cible de la phase individuelle. En d’autres termes, les paquets de la connexion UE2.CNX1 sont échangés dans la phase commune du flux.
Flux Raf1 Nombre de phases individuelles libres ou type de l’instance Nombre total de phases individuelles
Figure pctxmlib-appb-M000138
 (ou utilisé par une instance)
Figure pctxmlib-appb-M000139
 (Mbps)
Figure pctxmlib-appb-M000140
 (s)
Figure pctxmlib-appb-M000141
 (Mo)
Contrôle 0 1 5 3 3
UE1.CNX1 Individuel 1 5 2 2
UE2.CNX1 commun 0 0 0 0
Table 5 : Table de gestion des phases individuelles
(t = 1 s après le début de la connexion UE1.CNX1)
On note que comme l’équipement utilisateur UE2 est arrivé une seconde après l’équipement utilisateur UE1, le temps restant pour la connexion UE1.CNX1 sur la phase individuelle du flux n’est plus que de 2s.
Lorsque le critère d’arrêt pour la transmission sur la phase individuelle est atteint, la phase individuelle est libérée et disponible pour une autre transmission.
Ainsi, si l’on se place 3,5 secondes après début de la connexion UE1.CNX1 (avec Ti_1 = 3 s), la phase individuelle utilisée pour la transmission des données de début de connexion vers l’équipement utilisateur UE1 est libérée, et la transmission des données UE1.CNX1 se poursuit sur la phase commune du flux, à un débit inférieur au débit cible
Figure pctxmlib-appb-M000142
:
Flux Raf1 Nombre de phases individuelles libres ou type de l’instance Nombre total de phases individuelles
Figure pctxmlib-appb-M000143
 (ou utilisé par une instance)
Figure pctxmlib-appb-M000144
 (Mbps)
Figure pctxmlib-appb-M000145
 (s)
Figure pctxmlib-appb-M000146
 (Mo)
Contrôle 1 1 5 3 3
UE1.CNX1 Commun 0 0 0 0
UE2.CNX1 Commun 0 0 0 0
Table 6 : Table de gestion des phases individuelles
(t = 3,5 s après le début de la connexion UE1.CNX1)
On suppose désormais que l’équipement utilisateur UE3 souhaite établir une connexion avec le serveur S3. Par exemple, l’UE3 envoie un message de type « ClientHello » au serveur S3.
Le module RRC détecte cette nouvelle connexion UE3.CNX1 dans les flux IP reçu par le satellite, par exemple 4 secondes après le début de la connexion UE1.CNX1.
Comme le nombre de phases individuelles libre est égal à 1 (cf table 6), cela signifie qu’une phase individuelle est disponible pour le flux quand le début de la connexion UE3.CNX1 est détecté. Il est donc possible de transmettre les données de début de connexion en provenance du serveur de données S3, entre le satellite SAT et l’équipement utilisateur UE3, au débit cible de la phase individuelle (Di_1 = 5 Mbps), jusqu’à un critère d’arrêt (par exemple pendant une durée Ti_3 = 3 s).
Flux Raf1 Nombre de phases individuelles libres ou type de l’instance Nombre total de phases individuelles
Figure pctxmlib-appb-M000147
 (ou utilisé par une instance)
Figure pctxmlib-appb-M000148
 (Mbps)
Figure pctxmlib-appb-M000149
 (s)
Figure pctxmlib-appb-M000150
 (Mo)
Contrôle 0 1 5 3 3
UE1.CNX1 Commun 0 0 0 0
UE2.CNX1 Commun 0 0 0 0
UE3.CNX1 Individuel 1 5 3 3
Table 7 : Table de gestion des phases individuelles
(t = 4 s après le début de la connexion UE1.CNX1)
Le module RRC peut notamment envoyer un signal de début de connexion individuelle DebCoFlag au module RLC, ou directement au module MAC, dans une étape 75. Comme indiqué précédemment, un tel signal, également appelé indicateur de début de connexion, peut être transporté de différentes manières :
  • dans un entête propriétaire,
  • dans un bit inutilisé, par exemple un des bits réservés du « spin-bit » du protocole QUIC,
  • dans un entête non propriétaire, par exemple iOAM, ECN, etc, pour accroitre l’interopérabilité,
  • etc.
Le choix du transport du signal dépend notamment de la localisation des blocs RLC, RRC et MAC, qui dépend du « split » choisi et/ou des constructeurs de ces blocs. Par exemple, dans le cas du split eCPRI A ou B (3GPP option 1 ou 2) et d’une implémentation du bloc MAC et du bloc RRC par des constructeurs différents, ce signal est préférentiellement transporté d’une façon prédéterminée entre ces blocs.
Dans une étape 76, un tel signal de début de connexion est par exemple ajouté par le module RLC dans les premières trames des paquets portant les données de début de connexion reçues du serveur S1 (UE1.Cnx1_data).
Éventuellement, un indicateur de fin de connexion FinCoFlag peut être transmis (77) au module RLC ou au module MAC. Par exemple, l’indicateur de début de connexion DebCoFlag et l’indicateur de fin de connexion FinCoFlag sont transmis dans des signaux séparés, et marquent uniquement le premier et le dernier paquet portant les données de début de connexion reçues du serveur S1. Ces signaux peuvent être envoyés directement au module MAC.
En variante, une information de durée DebCoDuration ou de volume DebCoVol peut être transmise au module RLC ou au module MAC. L’information de durée DebCoDuration correspond notamment à la durée
Figure pctxmlib-appb-M000151
 d’une phase individuelle telle que définie dans la table de gestion des phases individuelles. L’information de volume DebCoVol correspond notamment à un volume
Figure pctxmlib-appb-M000152
 de données à transmettre dans une phase individuelle tel que défini dans la table de gestion des phases individuelles. Par exemple l’indicateur de début de connexion DebCoFlag peut être un entier correspondant à l’information de durée DebCoDuration et donc décrémenté avec le temps. En variante, l’indicateur de début de connexion DebCoFlag correspond à l’information de volume DebCoVol et donc décrémenté avec la taille de chaque trame des paquets accélérés.
A réception des trames, le module MAC vérifie la présence d’un signal de début de connexion DebCoFlag. Si un signal de début de connexion DebCoFlag est détecté, il émet les données correspondantes dans la phase individuelle du flux du spot (781). Sinon, il émet les trames dans la phase commune du flux du spot, s’il dispose de ressources radio en émission. Sinon, les trames peuvent être mises en mémoire (« buffer ») ou « poubellisées » par le module MAC.
Passé le délai DebCoDuration ou le volume DebCoVol, ou à réception d’un signal de fin de connexion FinCoFlag, le module RLC ne marque plus les trames (79). Le module MAC émet donc les trames portant des données de « poursuite de connexion » dans la phase commune du flux du spot (782), s’il dispose de ressources radio en émission. Sinon, les trames peuvent être mises en mémoire (« buffer ») ou poubellisées par le module MAC.
En variante, le module RLC peut mettre en mémoire ou « poubelliser » les trames non marquées suivant le type de module RLC (Transparent Mode (TM), Unacknowledged Mode (UM) ou Acknowledged Mode (AM)).
Si l’équipement utilisateur UE1 se reconnecte ultérieurement au même serveur S1, la phase 0-RTT du protocole QUIC est mise en œuvre (UE1.Cnx2 end to end starts : ClientHello 0-RTT phase »). Dans ce cas, le module MAC peut directement émettre les trames portant des données reçues du serveur S1 dans la phase commune du flux du spot.
5.3 Variantes
On a décrit ci-dessus des exemples dans lesquels l’équipement intermédiaire mobile est un satellite. D’autres équipements d’accès mobiles peuvent bien entendu être utilisés, par exemple un avion, un ballon, un drone, une HIBS, etc.
De même, on a décrit une mise en œuvre de l’invention lorsque les modules RRC, RLC et MAC sont co-localisés dans l’équipement intermédiaire mobile. En variante, selon le « split » choisi, certains modules peuvent être localisés à distance. Dans ce cas, les différents signaux échangés (indicateur de début et/ou fin de connexion, tables, etc) devront présenter un format compatible avec les différents modules pour pouvoir être traités.
Plus généralement, l’invention peut être mise en œuvre dans les différentes architectures décrites en relation avec la (« Nothing on board », « RU onboard », « RU+DU onboard », « RU+DU+CU onboard »).
On a également présenté un exemple selon lequel une seule phase individuelle est disponible. Dans d’autres modes de réalisation, plusieurs phases individuelles peuvent être disponibles.
En revenant à l’exemple décrit ci-dessus en relation avec les figures 6 et 7, on présente ci-après quelques variantes.
Selon un mode de réalisation particulier, l’OSS du MNO peut mettre à jour certains paramètres, notamment pour les connexions existantes en cours sur la phase individuelle.
Par exemple, si l’algorithme de calcul de la capacité présenté ci-dessus propose de raccourcir la durée
Figure pctxmlib-appb-M000153
 d’une phase individuelle pour répondre à l’arrivée de plusieurs nouveaux équipements utilisateurs dans la cellule radio, en plus de UE1, alors la durée
Figure pctxmlib-appb-M000154
 de la connexion en cours UE1.CNX1 peut être réduite, par exemple de 5%, pour accepter un peu plus tôt la connexion UE2.CNX2 dans la phase individuelle.
Selon un autre exemple, il est possible de donner la priorité à une demande de création d’une connexion UE2.CNX2 d’un service de secours. Dans ce cas, la durée de la connexion en cours UE1.CNX1 peut être forcée par l’OSS du MNO ou du SNO, par exemple à 95%, pour accélérer le passage en phase commune de la transmission, afin d’accepter immédiatement la connexion UE2.CNX2 au service de secours dans la phase individuelle.
Ces différents exemples illustrent que les paramètres peuvent être choisis ou mis à jour en tenant compte du service ou du domaine du serveur demandé. Par exemple, une connexion vers un domaine video.example.com peut obtenir au démarrage le double de temps
Figure pctxmlib-appb-M000155
 ou de mega octets
Figure pctxmlib-appb-M000156
.
Ce cas s’applique notamment aux connexions affichant leur type d’application (comme IETF APN BoF, MASQUE WG) ou dans le cas d’une coopération d’un des BSS avec un CDN (« Content Delivery Network ») souhaitant accélérer un service.
Par ailleurs, comme indiqué ci-dessus, dans l’implémentation la plus simple, le module RRC peut classer les phases 1-RTT pour transmettre les données correspondantes sur une phase individuelle du flux, et les phases 0-RTT pour les transmettre sur une phase commune.
Dans un mode plus perfectionné, les phases initiales des connexions QUIC 0-RTT peuvent également être transmises sur une phase individuelle du flux si une telle phase individuelle est disponible. Cette phase individuelle peut avoir des paramètres différents (notamment
Figure pctxmlib-appb-M000157
,
Figure pctxmlib-appb-M000158
 et/ou
Figure pctxmlib-appb-M000159
), par exemple avec un basculement sur la phase commune plus rapide (
Figure pctxmlib-appb-M000160
 par exemple). Cette réduction tient compte du moindre besoin de données en début de reconnexion du fait de la présence de données applicatives dans le cache de l’équipement utilisateur.
Dans un autre mode de réalisation, les champs du certificat CN (« Common Name ») ou SAN (« Subject Alternative Name ») peuvent être utilisés par le module RRC ou l’un des BSS pour identifier un partenaire CDN, un type de service ou un nom de domaine, et lui associer un contrôle personnalisé. Optionnellement ces paramètres diffèrent avec le service ou le domaine du serveur demandé.
Dans une première implémentation, le BSS peut fournir ces règles au module RRC dans une table de personnalisation des phases individuelles. Cette implémentation permet le classement de la connexion dès la détection de la connexion.
Par exemple, dans la table de personnalisation ci-dessous, une connexion vers un domaine video.example.com obtient au démarrage le double de temps
Figure pctxmlib-appb-M000161
 ou de mega octets
Figure pctxmlib-appb-M000162
. En revanche, le domaine foo.example.com sera lui toujours classé pour être transmis dans la phase commune.
De plus, les connexions venant du sous réseau IP 192.168.1.0/24 ou du domaine samu.example.com préemptent les connexions en cours sur la phase individuelle, sans prendre les ressources de la phase commune, avec une durée infinie et un volume illimité.
service
Figure pctxmlib-appb-M000163
 (Mbps)
Figure pctxmlib-appb-M000164
 (s)
Figure pctxmlib-appb-M000165
 (Mo)
video.example.com 5 6 6
foo.example.com 0 0 0
IP source 192.168.1.0/24 5 0 0
Domaine source samu.example.com 10 0 0
Table 8 : Table de personnalisation des phases individuelles
Dans une seconde implémentation, une colonne « service », recevant le domaine de la connexion peut être ajoutée à la table de gestion des phases individuelles afin que l’OSS/BSS du MNO applique ces règles aux connexions en cours. Cette implémentation permet le classement des connexions en cours après réception de la table de gestion des phases individuelles.
Selon cette implémentation, en reprenant les tables 5, 6 et 7 présentées ci-dessus, lorsque le module RRC détecte la nouvelle connexion UE2.CNX1 dans les flux IP reçu par le satellite, par exemple une seconde après le début de la connexion UE1.CNX1, on a :
Flux Raf1 Nombre de phases individuelles libres ou type de l’instance Nombre total de phases individuelles
Figure pctxmlib-appb-M000166
 (ou utilisé par une instance)
Figure pctxmlib-appb-M000167
 (Mbps)
Figure pctxmlib-appb-M000168
 (s)
Figure pctxmlib-appb-M000169
 (Mo)		 Service
Contrôle 0 1 5 3 3
UE1.CNX1 Individuel 1 5 2 2 video.example.com
UE2.CNX1 commun 0 0 0 0 foo.example.com
Table 9 : Table de gestion des phases individuelles après personnalisation, reçue de RaF1 une seconde après le début de la connexion UE1.CNX1
Flux Raf1 Nombre de phases individuelles libres ou type de l’instance Nombre total de phases individuelles
Figure pctxmlib-appb-M000170
 (ou utilisé par une instance)
Figure pctxmlib-appb-M000171
 (Mbps)
Figure pctxmlib-appb-M000172
 (s)
Figure pctxmlib-appb-M000173
 (Mo)		 Service
Contrôle 0 1 5 3 3
UE1.CNX1 individuel 1 5 5 5 video.example.com
UE2.CNX1 commun 0 0 0 0 foo.example.com
UE2.CNX1 commun 0 0 0 0 foo.example.com
Table 10 : Table de gestion des phases individuelles après personnalisation, émise par l’OSS/BSS vers le RaF1
Lorsque le module RRC détecte la nouvelle connexion UE3.CNX1 dans les flux IP reçu par le satellite, par exemple 4 secondes après le début de la connexion UE1.CNX1, on a :
Flux Raf1 Nombre de phases individuelles libres ou type de l’instance Nombre total de phases individuelles
Figure pctxmlib-appb-M000174
 (ou utilisé par une instance)
Figure pctxmlib-appb-M000175
 (Mbps)
Figure pctxmlib-appb-M000176
 (s)
Figure pctxmlib-appb-M000177
 (Mo)		 service
Contrôle 0 1 5 3 3
UE1.CNX1 individuel 1 5 1 1
UE2.CNX1 commun 0 0 0 0
UE3.CNX1 commun 0 0 0 0
Table 7 : Table de gestion des phases individuelles après personnalisation
On note que la transmission avec le premier équipement utilisateur UE1.CNX1 est toujours dans la phase individuelle du flux du spot. En revanche, la transmission avec le troisième équipement utilisateur UE3.CNX1 est dans la phase commune du flux, puisque le nombre de phases individuelles libre est toujours à zéro.
En particulier, le choix de l’implémentation de la personnalisation ci-dessus dépend de la localisation du bloc RRC de l’unité centralisée CU. Une localisation « embarquée » du CU (distante de l’OSS/BSS) implique le choix d’un mode de transport commun (une standardisation) de la table de personnalisation des phases individuelles / table de gestion des phases individuelles après personnalisation.
5.4 Système correspondant
On présente finalement la structure simplifiée d’un système de gestion des communications selon au moins un mode de réalisation décrit ci-dessus, comprenant des modules d’obtention du nombre de phases individuelles, de détection d’un début de connexion, et de transmission de données de début de connexion.
Comme déjà indiqué, ces modules peuvent être co-localisés au sein d’un même équipement (par exemple un équipement géré par l’opérateur mobile ou par l’opérateur satellite), ou distants.
Selon l’exemple illustré en , au moins un équipement d’un tel système comprend au moins une mémoire 81 comprenant une mémoire tampon, au moins une unité de traitement 82, équipée par exemple d’une machine de calcul programmable ou d’une machine de calcul dédiée, par exemple un processeur P, et pilotée par le programme d’ordinateur 83, mettant en œuvre des étapes du procédé de gestion des communications selon au moins un mode de réalisation de l’invention.
A l’initialisation, les instructions de code du programme d’ordinateur 83 sont par exemple chargées dans une mémoire RAM avant d’être exécutées par le processeur de l’unité de traitement 82.
Le processeur de l’unité de traitement 82 met en œuvre des étapes du procédé de gestion des communications décrit précédemment, selon les instructions du programme d’ordinateur 83, pour :
  • obtenir un nombre de phases individuelles associées chacune à un débit cible dans ledit flux, à servir pour des transmissions dudit équipement intermédiaire mobile vers ladite cellule radio,
  • détecter un début de connexion d’un premier équipement utilisateur, présent dans ladite cellule radio, avec un premier serveur de données, via ledit équipement intermédiaire mobile,
  • transmettre des données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, au débit cible de la phase individuelle, jusqu’à un critère d’arrêt, si une phase individuelle est disponible pour ledit flux, ou
  • transmettre des données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, à un débit inférieur audit débit cible, si aucune phase individuelle n’est disponible pour ledit flux.
Selon un mode de réalisation particulier, ces différentes étapes peuvent être mises en œuvre par des modules physiques ou logiciels, co-localisés ou distants.

Claims (11)

  1. Procédé de gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement intermédiaire mobile générant au moins un faisceau radio couvrant une zone géographique terrestre, dite cellule radio, caractérisé en ce qu’il met en œuvre les étapes suivantes, pour un flux de données dudit au moins un faisceau radio :
    • obtention (41) du nombre d’ensembles de ressources radio du flux de données du faisceau radio, utilisés pour les transmissions entre l’équipement intermédiaire mobile et au moins un premier équipement utilisateur présent dans la cellule radio, un ensemble de ressources radio permettant d’atteindre un débit cible,
    • détection (42) d’un début de connexion d’un premier équipement utilisateur, présent dans ladite cellule radio, avec un premier serveur de données, via ledit équipement intermédiaire mobile,
    • si un ensemble de ressources radio permettant d’atteindre un débit cible est disponible pour ledit flux : transmission (431) de données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, audit débit cible, jusqu’à un critère d’arrêt,
    • si aucun ensemble de ressources radio permettant d’atteindre un débit cible n’est disponible pour ledit flux : transmission (432) de données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, à un débit inférieur audit débit cible.
  2. Procédé selon la revendication 1, caractérisé en ce que le nombre d’ensembles de ressources radio dudit flux est défini à partir d’au moins un paramètre appartenant au groupe comprenant :
    • ledit débit cible
      Figure pctxmlib-appb-M000178
      ,
    • une puissance d’émission
      Figure pctxmlib-appb-M000179
       dudit équipement intermédiaire mobile,
    • un facteur de propagation
      Figure pctxmlib-appb-M000180
       entre ledit équipement intermédiaire mobile et ladite cellule radio, ou au moins un équipement utilisateur présent dans ladite cellule radio,
    • une bande passante
      Figure pctxmlib-appb-M000181
      dudit équipement intermédiaire mobile,
    • un angle d’ouverture de l’antenne d’émission
      Figure pctxmlib-appb-M000182
       dudit équipement intermédiaire mobile,
    • une distance
      Figure pctxmlib-appb-M000183
       entre ledit équipement intermédiaire mobile et ladite cellule radio, ou au moins un équipement utilisateur présent dans ladite cellule radio,
    • un nombre de faisceaux radio interférents
      Figure pctxmlib-appb-M000184
       entre ledit équipement intermédiaire mobile et au moins une autre cellule radio,
    • un bruit thermique
      Figure pctxmlib-appb-M000185
      ,
    • la variance de l’effet de masque
      Figure pctxmlib-appb-M000186
      ,
    • une probabilité de non-couverture
      Figure pctxmlib-appb-M000187
      .
  3. Procédé selon la revendication 2, caractérisé en ce que le nombre d’ensembles de ressources radio dudit flux est égal à la partie entière de la capacité
    Figure pctxmlib-appb-M000188
     dudit faisceau radio
    Figure pctxmlib-appb-M000189
    ) avec :
    Figure pctxmlib-appb-M000190
    Figure pctxmlib-appb-M000191
    • Figure pctxmlib-appb-M000192
      ).
  4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ledit critère d’arrêt dépend d’un type de service.
  5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ledit critère d’arrêt appartient au groupe comprenant :
    • une période donnée
      Figure pctxmlib-appb-M000193
      ,
    • un volume donné
      Figure pctxmlib-appb-M000194
      ,
    • une fin de connexion dudit premier équipement utilisateur avec ledit premier serveur de données,
    • une détection d’un début de connexion d’un deuxième équipement utilisateur, présent dans ladite cellule radio, à un deuxième serveur de données prioritaire par rapport audit premier serveur de données.
  6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ladite étape d’obtention du nombre d’ensembles de ressources radio est mise à jour :
    • périodiquement, ou
    • suite à une modification d’un paramètre dudit équipement intermédiaire mobile, ou
    • suite à une modification d’un paramètre dudit faisceau radio généré par ledit équipement intermédiaire mobile, ou
    • suite à une modification dudit critère d’arrêt.
  7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ladite détection d’un début de connexion met en œuvre la détection d’un échange de données de sécurisation de la connexion entre ledit premier équipement utilisateur et ledit premier serveur de données.
  8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que ladite détection d’un début de connexion comprend :
    • l’identification desdites données de début de connexion, à partir d’au moins un marqueur inséré par un module de type RRC dans au moins un paquet de données en provenance dudit premier serveur de données,
    • l’insertion desdites données de début de connexion dans l’ensemble de ressources radio disponible pour ledit flux par un module de type MAC.
  9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu’il met en œuvre le stockage d’informations relatives à ledit au moins un ensemble de ressources radio dans une table de gestion des ensembles de ressources radio.
  10. Système de gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement intermédiaire mobile générant au moins un faisceau radio couvrant une zone géographique terrestre, dite cellule radio, caractérisé en ce qu’il comprend, pour un flux de données dudit au moins un faisceau radio :
    • un module d’obtention du nombre d’ensembles de ressources radio du flux de données du faisceau radio, utilisés pour les transmissions entre l’équipement intermédiaire mobile et au moins un premier équipement utilisateur présent dans la cellule radio, un ensemble de ressources radio permettant d’atteindre un débit cible,
    • un module de détection d’un début de connexion d’un premier équipement utilisateur, présent dans ladite cellule radio, avec un premier serveur de données, via ledit équipement intermédiaire mobile,
    • un module de transmission de données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, au débit cible d’un ensemble de ressources radio, jusqu’à un critère d’arrêt, activés si un ensemble de ressources radio est disponible pour ledit flux, et
    • un module de transmission de données de début de connexion en provenance dudit premier serveur de données, entre ledit équipement intermédiaire mobile et ledit premier équipement utilisateur, à un débit inférieur audit débit cible, activés si aucun ensemble de ressources radio n’est disponible pour ledit flux.
  11. Programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé selon l'une quelconque des revendications 1 à 9, lorsqu’il est exécuté par un processeur.
PCT/EP2022/081021 2021-11-12 2022-11-07 Procédé de gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement intermédiaire mobile, système et programme d'ordinateur correspondants WO2023083763A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2112016 2021-11-12
FR2112016A FR3129265A1 (fr) 2021-11-12 2021-11-12 Procédé de gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement intermédiaire mobile, système et programme d’ordinateur correspondants.

Publications (1)

Publication Number Publication Date
WO2023083763A1 true WO2023083763A1 (fr) 2023-05-19

Family

ID=80787492

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/081021 WO2023083763A1 (fr) 2021-11-12 2022-11-07 Procédé de gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement intermédiaire mobile, système et programme d'ordinateur correspondants

Country Status (2)

Country Link
FR (1) FR3129265A1 (fr)
WO (1) WO2023083763A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130337822A1 (en) * 2012-06-13 2013-12-19 All Purpose Networks LLC Locating and tracking user equipment in the rf beam areas of an lte wireless system employing agile beam forming techniques
US20150016253A1 (en) * 2013-07-11 2015-01-15 Viasat, Inc. Source-aware network shaping
US20190068331A1 (en) * 2016-02-26 2019-02-28 Lg Electronics Inc. Method for executing harq in wireless communication system and device therefor
WO2020138985A1 (fr) * 2018-12-26 2020-07-02 엘지전자 주식회사 Procédé permettant de fournir un service de communication dans un système de communication sans fil

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130337822A1 (en) * 2012-06-13 2013-12-19 All Purpose Networks LLC Locating and tracking user equipment in the rf beam areas of an lte wireless system employing agile beam forming techniques
US20150016253A1 (en) * 2013-07-11 2015-01-15 Viasat, Inc. Source-aware network shaping
US20190068331A1 (en) * 2016-02-26 2019-02-28 Lg Electronics Inc. Method for executing harq in wireless communication system and device therefor
WO2020138985A1 (fr) * 2018-12-26 2020-07-02 엘지전자 주식회사 Procédé permettant de fournir un service de communication dans un système de communication sans fil

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
3GPP TS 38.322

Also Published As

Publication number Publication date
FR3129265A1 (fr) 2023-05-19

Similar Documents

Publication Publication Date Title
CN102550082A (zh) 共享无线广域网调制解调器的选择和利用
Marchese et al. DTN-based nanosatellite architecture and hot spot selection algorithm for remote areas connection
EP1464148B1 (fr) Procede de gestion de communications dans un reseau, signal, dispositif et terminal recepteur correspondants.
CN115804036A (zh) 数字服务的可靠传递
WO2022012141A1 (fr) Procédé et appareil de transmission d'informations, et support de stockage
WO2019185552A1 (fr) Procede de communication
CN114788246A (zh) 用于边缘计算服务的方法和装置
FR2884999A1 (fr) Reseau de communication mobile et de videodiffusion serveur et procede d'exploitation
EP2210396B1 (fr) Système d'interconnexion entre au moins un appareil de communication et au moins un système d'information distant et procédé d'interconnexion
EP3370363B1 (fr) Solution de transport de données hybride notamment pour liaisons par satellite
FR2883440A1 (fr) Procede et equipement pour la transmission de donnees par reseau ad hoc
WO2023083763A1 (fr) Procédé de gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement intermédiaire mobile, système et programme d'ordinateur correspondants
US20220239589A1 (en) Method and apparatus for distributing network traffic over multiple communication networks
EP3777308A1 (fr) Procede de communication
CN113783963A (zh) 数据传输方法、服务器节点、网关设备、网络系统
FR3065141B1 (fr) Procede d'allocation d'une ressource de transmission a un terminal mobile
WO2023275490A1 (fr) Procede de traitement d'une connexion entre un equipement utilisateur et un equipement distant dans un reseau de communication, procede de controle, dispositifs, satellite, station terrestre, systeme et programmes d'ordinateur correspondants
FR2900528A1 (fr) Procede et systeme pour accelerer l'acces a un contenu a partir d'un terminal mobile
WO2024002868A1 (fr) Procédés de fourniture et de collecte, station de base, dispositif de collecte et d'analyse de données et système
Gotta et al. A TCP/IP satellite infrastructure for sensing operations in emergency contexts
US20180227220A1 (en) Router Cooperation
WO2024002867A1 (fr) Collecte d'informations sur le déploiement des cellules
WO2020120850A1 (fr) Terminal pouvant être connecté simultanément à plusieurs réseaux d'accès, procédé de différentiation de trafic émis par le terminal, dispositif et procédé de gestion du trafic
CN117440468A (zh) 一种通信方法及装置
WO2020109694A1 (fr) Procédé de préemption de ressources de transmission pour l'acheminement de données temps réel

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22814010

Country of ref document: EP

Kind code of ref document: A1