WO2019193154A1 - Gestion de latence de nœuds radio - Google Patents

Gestion de latence de nœuds radio Download PDF

Info

Publication number
WO2019193154A1
WO2019193154A1 PCT/EP2019/058646 EP2019058646W WO2019193154A1 WO 2019193154 A1 WO2019193154 A1 WO 2019193154A1 EP 2019058646 W EP2019058646 W EP 2019058646W WO 2019193154 A1 WO2019193154 A1 WO 2019193154A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
time
transmission
base station
delay
Prior art date
Application number
PCT/EP2019/058646
Other languages
English (en)
Other versions
WO2019193154A9 (fr
Inventor
Anders Jonsson
Angelo Centonza
Alessandro CAVERNI
Irfan BEKLEYEN
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Publication of WO2019193154A1 publication Critical patent/WO2019193154A1/fr
Publication of WO2019193154A9 publication Critical patent/WO2019193154A9/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H04L43/0858—One way delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H04L43/106—Active monitoring, e.g. heartbeat, ping or trace-route using time related information in packets, e.g. by adding timestamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0231—Traffic management, e.g. flow control or congestion control based on communication conditions
    • H04W28/0236—Traffic management, e.g. flow control or congestion control based on communication conditions radio quality, e.g. interference, losses or delay
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/24—Reselection being triggered by specific parameters
    • H04W36/30—Reselection being triggered by specific parameters by measured or perceived connection quality data
    • H04W36/304—Reselection being triggered by specific parameters by measured or perceived connection quality data due to measured or perceived resources with higher communication quality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0083—Determination of parameters used for hand-off, e.g. generation or modification of neighbour cell lists
    • H04W36/0085—Hand-off measurements
    • 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/08—Access point devices
    • H04W88/085—Access point devices with remote components
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/04—Interfaces between hierarchically different network devices
    • H04W92/12—Interfaces between hierarchically different network devices between access points and access point controllers

Definitions

  • the present disclosure relates generally to communications, and more particularly, to wireless communications and related wireless devices and network nodes.
  • the next generation (NG) architecture comprises a NG-RAN including a set of 5G/NG base stations (gNBs) connected to the 5G core network (5GC) through the NG.
  • a gNB can support frequency division duplex (FDD) mode, time division duplex (TDD) mode, or dual mode operation.
  • the gNBs can be interconnected through a logical interface, Xn.
  • a gNB may include a Central Unit, (gNB-)CU, and one or a plurality of Distributed Units, (gNB-)DUs.
  • NG-RAN 5G Radio Access Network
  • a CU may be regarded as a logical node or unit that includes a (first) subset gNB functions, such as Transfer of user data, Mobility control, Radio access network sharing, Positioning, Session Management.
  • the CU controls the operation of DUs over a front-haul (Fs) interface.
  • Fs front-haul
  • a DU may be regarded as logical node or unit that includes a (second) subset of the gNB functions, depending on a chosen (functional) split between the first subset and second subset of gNB functions. Its operation is controlled by the CU.
  • a gNB-CU connects to gNB-DUs each via a Fl interface.
  • One gNB-DU may be connected to only one gNB-CU, but a gNB-CU may control one or a plurality of gNB-DUs.
  • NG, Xn, and Fl may be regarded as logical interfaces (i.e. as providing interconnection of logical nodes, wherein a logical node encompasses a set of functions e.g. as defined in appropriate standard documents).
  • the NG and Xn-C interfaces for a gNB can include a gNB-CU and gNB-DUs, and the NG and Xn-C interfaces can terminate in the gNB- CU.
  • EN (E-UTRAN)-DC, Sl-U, and X2-C interfaces for a gNB including a gNB-CU and gNB-DUs can terminate in the gNB-CU.
  • the gNB-CU and connected gNB-DUs may only be visible to other gNBs and the 5GC as a gNB.
  • the NG-RAN is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL).
  • RNL Radio Network Layer
  • TNL Transport Network Layer
  • the NG-RAN architecture including the NG-RAN logical nodes and interfaces between them, can be defined as part of the RNL. Lor each NG-RAN interface (NG, Xn, Ll) the related TNL protocol and the functionality can be specified.
  • the TNL can provide services for user plane transport and signaling transport.
  • each gNB can be connected to all AMFs within an AMF Region.
  • the AMF Region is e.g. described in 3GPP TS 23.501 (version 15.1.0).
  • the Fl interface provides means for interconnecting a gNB-CU and a gNB-DU of a gNB within an NG-RAN, or for
  • gNB-CU interconnecting a gNB-CU and a gNB-DU of an en-gNB (E-UTRAN/NR NB) within an E- UTRAN.
  • E-UTRAN/NR NB en-gNB
  • Fl may be open and support the exchange of signaling information between endpoints.
  • the Fl interface may support data transmission to respective endpoints.
  • the Fl interface may be a point-to-point interface between endpoints.
  • a point-to-point logical interface can be feasible in the absence of a physical direct connection between the endpoints.
  • the Fl interface can support control plane and user plane separation.
  • the Fl interface can separate Radio Network Fayer (RNF) and Transport Network Fayer (TNF).
  • RMF Radio Network Fayer
  • TNF Transport Network Fayer
  • the Fl interface can enable exchange of UE associated information and non-UE associated information.
  • the Fl interface can be defined to be future proof to fulfil different new requirements, support new services, and provide new functions.
  • One gNB-CU and set of gNB-DUs can be visible to other logical nodes as a gNB.
  • the gNB can terminate X2, Xn,
  • the gNB-CU may be separated in a control plane (CP) and a user plane (UP).
  • CP control plane
  • UP user plane
  • Fig. 2 depicts the interface protocol structure for the Fl user plane.
  • the first five layers may be regarded to form the Transport Network layer with the GTP-U (GPRS Tunneling Protocol User plane) layer on top and UDP, IP, data link layer and physical layer below.
  • GTP-U GPRS Tunneling Protocol User plane
  • the Transport network layer defines procedures for establishing physical connections between the corresponding nodes, whereas the Radio Network Fayer (depicted on top of the GTP-U) defines procedures related to the interaction of this nodes.
  • gNB base station
  • RTT Round Trip Time
  • the local time reference in the transmitting node can be used both to determine the transmission and reception time.
  • the one-way delay UL and/or DL
  • separate time references are used in the transmitting node to determine the transmission time while and in the receiving node to determine the reception time. Only If both these time references are synchronized, the measurement of each one-way delay will be accurate Otherwise, the delay measurement will be erroneous in proportion to the (unknown) time difference between the time references in the transmitting and receiving nodes.
  • the clocks of the different nodes may be synchronized by exchanging appropriate synchronization messages.
  • GPS Global Positioning System
  • synchronizing clocks in a variable delay packet network can be problematic since also packets sent to synchronize the clocks experience variable delay and consequently it is difficult to accomplish.
  • NTP Network Time Protocol
  • NTP may maintain a time synchronization to within tens of milliseconds over the public Internet and may achieve better than one millisecond accuracy in local area networks under ideal conditions.
  • the Precision Time Protocol may be used.
  • PTP may achieve a clock accuracy in the sub-microsecond range, making it suitable for measurement and control systems.
  • the PTP may be regarded as to fill a niche not well served by either of the two dominant protocols, NTP and GPS.
  • It is an object of the present invention to improve an operation of functionally split base stations comprising a central unit and one or a plurality of distributed units.
  • a method is provided to handle transmission delays in a radio access network involving a plurality of nodes or units.
  • the plurality of units or nodes are a (gNB) Central Unit (CU) and one or a plurality of (gNB) Distributed units (DUs) comprised by a gNB.
  • suitable information metrics is being sent from one unit to another unit to determine delay characteristics between the units.
  • Information of the delay characteristics gathered at one unit may further be provided to the other unit.
  • a method in a central unit, CU, of a base station, gNB (or eNB), is performed to determine a time delay to one or a plurality of distributed units, DUs, wherein the CU provides an interface to a core radio network, CN, and the DUs provides each a radio interface to one or a plurality of UEs, comprising:
  • a method in a distributed unit, DU, of a base station, gNB (or eNB), is performed to determine a time delay to a CU, wherein the CU provides an interface to a core radio network, CN, and the DU provides a radio interface to one or a plurality of UEs, comprising:
  • a CU (of a base station) configured to perform:
  • a DU(of a base station) configured to perform:
  • a UE is provided to support the gNB to determine the transmission delay information.
  • Fig. 1 schematically illustrates 5G network comprising an NG RAN and a 5G core network
  • Fig. 2 schematically illustrates exemplary user plane protocol being used in the NG RAN
  • Fig. 3 schematically illustrates a gNB of the NG RAN comprising a central unit, CU and two distributed units (DUs);
  • Fig. 4 schematically illustrates an exemplary PDU information element of the user plane protocol
  • Fig. 5 shows a sequence of steps being performed between a CU and a DU for determining transmission delays
  • Fig. 6 schematically illustrates a block diagram of a DU
  • Fig. 7 schematically illustrates a block diagram of a CU
  • Fig. 8 schematically illustrates a block diagram of a UE
  • Fig. 9 schematically illustrates a telecommunication network connected via an intermediate network to a host computer
  • Fig. 10 is a generalized block diagram of a host computer communicating via a base station with a user equipment over a partially wireless connection;
  • FIGS 11 to 14 are flowcharts illustrating methods implemented in a communication system including a host computer, a base station and a user equipment.
  • the solution outlined in the following outlines suitable metrics to be sent from one node or unit to another node or unit, e.g. from a DU and to a CU and/or vice versa, to determine delay characteristics between the units and how to convey this information between said units.
  • this information in conveyed via in-band signaling in a NR user plane data frame as outlined in following.
  • each frame sent in the uplink or the downlink can be timestamped with the transmission time.
  • timestamping a data packet such as the timestamp information element contained in the Internet Control Message Protocol (ICMP) or the Unix time (also known as POSIX time or UNIX Epoch time).
  • ICMP Internet Control Message Protocol
  • Unix time also known as POSIX time or UNIX Epoch time
  • An advantage of embodiments described is to provide a possibility to determine separate uplink and downlink delay characteristics between the CU and the DU, to convey this information e.g. via the NR user plane in-band signaling in the sense of 3GPP standard TS 38.425 NR User plane specification (version 15.0.0), and/or to perform actions based on the delay information, e.g. performing actions in case of certain links between a CU and one or a plurality of DUs not fulfilling certain (predefined) Quality of Service requirements, e.g. VoIP delay requirements, or for determining load balancing or admission and congestion decisions.
  • 3GPP standard TS 38.425 NR User plane specification version 15.0.0
  • Delay statistics that can determine not only RTT but also separate UL and DL delay characteristics may form important tools for managing Network Services and for Operations and Management (O&M) systems. Since the measurement functionality described herein may be applied on individual frames, both an actual UL and DL delay can be determined as well as statistics over time (or bin type measurements), where delay statistics can be gathered to determine a statistical distribution over time.
  • OFDM Operations and Management
  • Embodiments allow also to determine a radio network end-to-end delay (e.g. between a User Equipment, UE and a CU of the gNB).
  • a radio network end-to-end delay e.g. between a User Equipment, UE and a CU of the gNB.
  • Such delay information may also support decisions on radio link configuration. For example, if a UE is configured with dual connectivity via two DUs, e.g. DU1 and DU2, both connected to the same CU, the information exchanged would allow the CU to evaluate the delay characteristics of both (Fl) links CU-DU1 and CU-DU2. In case a disparity between the CU- DU1 and CU-DU2 delays, it may take actions to provide equivalence between both connections (as dual connectivity brings the most advantages if the delay between CU and DUs is equivalent).
  • the gNB e.g. the CU of the gNB
  • the gNB may take appropriate actions.
  • one or a plurality of the following actions may be performed:
  • QoS flow to DRB (re)mapping may be regarded as the operation that the RAN (gNB) changes the mapping relation between a QoS flow and a DRB, i.e., a QoS flow is reconfigured to be carried on a different DRB.
  • a QoS flow is reconfigured to be carried on a different DRB.
  • remapping may take place when the gNB wants to move a QoS flow in the default DRB to a dedicated DRB.
  • the present DRB for a QoS flow may become unavailable due to the change of radio environment including handover.
  • the gNB may adjust DRB allocation to better cope with the current traffic conditions.
  • Fig. 3 shows a gNB 3320 with a CU 7000 being exemplarily connected to two DU’s, first DU 6100 and second DU 6200.
  • Each of the units may be equipped with a GTP-U layer functionality.
  • the user plane traffic is sent via the Fl-U interface as NR user plane frames according to 3GPP standard TS.38.425.
  • embodiments are described to exchange delay information between CU and DUs by means of of Fl NR (in-band) user plane frames.
  • Fl NR in-band
  • Embodiments described herein apply to any radio nodes communicating via a user plane, UP, protocol similar to or equal to the one defined in TS 38.425.
  • nodes communicating via such protocols are an LTE eNB and an NR gNB or two LTE eNBs (X2 inteface), or two NR gNBs (Xn inteface), or an LTE eNB-CU and an LTE eNB-DU.
  • a first unit e.g. CU 7000 sends a timestamped data packet, e.g. a PDU as defined in Fig. 4, to a second unit, e.g. to first DU 6100.
  • a timestamped data packet e.g. a PDU as defined in Fig. 4
  • Such timestamp may be indicative of a transmission time of the data packet (e.g. a time of a transmission of the GTP-U protocol layer to the lower layer).
  • the second (receiving) unit may determine a transmission delay between the two units based on a common time reference of both units. Such procedure may be performed in both directions, e.g. from DU to CU and from CU to DU.
  • the transmission delay(s) may be stored (each) locally (on DU and CU) or sent to (each) the other node.
  • each of a plurality of DUs (e.g. first DU 6100 and second DU 6200) will receive the information comprising a timestamp at which the received DL data packet (PDU) was transmitted by the CU.
  • each DU can determine the DL CU-DU delay e.g. by timestamping the arrival of the DL PDU.
  • each DU may determine a difference between the arrival time at the DU and the transmission time at the CU (arrival timestamp - transmission Timestamp).
  • a similar procedure may be repeated for UL. Consequently, the delay in both directions, e.g. the downlink and the uplink delay can be determined separately and may e.g. be used to determine a gNB RTT delay. Alternatively or additionally, separate UL and DL delays (also being referred to as one way delays) may be kept and used for taking actions as discussed above. In such case each receiving unit conveys such delay information back to the transmitting unit.
  • timestamp and delay information is conveyed by means of a data packet frame structure (type of frame) comprising a field for time information:
  • the time stamp data is inserted into the field for time information. If sending back the FI delay information the same type of frame may be used, but instead of the timestamp, the transmission delay data is inserted into the field for time information.
  • the common time reference is established by means of synchronizing the CU clock and DU clock(s).
  • the CU 7000 and the one or plurality of DUs 6100, 6200 each comprise a delay measurement function, e.g. a CU delay measurement function residing in the CU 7000 and a DU delay measurement function residing in the first DU 6100.
  • a delay measurement function e.g. a CU delay measurement function residing in the CU 7000 and a DU delay measurement function residing in the first DU 6100.
  • These use the timestamp information from the transmitting node and compare this with the local time reference in the receiving node to determine the corresponding one-way delay, e.g. a downlink data packet is timestamped in the CU which allows the DU to determine the DL delay.
  • the DU can generate a delay feedback information and send it to the CU.
  • the CU will allow the CU to determine the DL CU-DU delay.
  • the DU will also be aware of DL CU-DU delay.
  • the DL delay can then both be stored and accessible locally in the DU and also conveyed back to the CU by utilizing any of the protocols connecting the CU and DU, e.g. the NR user plane protocol as defined in 3GPP TS 38.425, as being described in more detail below.
  • Fig. 5 shows exemplary steps of determining the (Fl) DL and UL delay information.
  • (gNB-)CU 7000 and (first gNB-)DU 6100 may perform clock
  • CU 7000 sends a CU transmission time stamp to DU 6100.
  • DU 6100 determines the CU-DU (or DL) transmission delay based on the received CU transmission time stamp information and the current time of a clock
  • DU 6100 (DU clock).
  • DU 6100 may transmit the DL transmission delay information to CU 7000.
  • DU 6100 sends a DU transmission time stamp to CU 7000.
  • CU 7000 determines the DU-CU (or UL) transmission delay based on the received DU transmission time stamp information and the current time of a clock
  • CU 7000 may transmit the UL transmission delay information to DU 6100.
  • CU or DU may take further actions
  • two or more DUs 6100, 6200 are involved in the UE-gNB
  • the CU determines the DL delay information for CU-DU1 and CU-DU2 based on each a time stamp received from DU 1 and DU2.
  • the CU may determine a first DL delay DL1 between CU and DU1 and a second DL delay DL2 between CU and DU2.
  • the CU may further determine which delay is shorter. If the CU determines that DL1 is shorter that DL2, it may schedule traffic only via such leg comprising DU 1. It may remove the leg to the UE via DU2.
  • the UE may replace the leg over DU2 by a leg over DU 1.
  • an end-to-end (e2e) packet delay is determined, i.e. determining a time it takes for a packet that is generated at the UE to reach the gNB-CU, and vice versa (from gNB-CU to UE).
  • the end-to-end measurement (user equipment - gNB-CU, and vice versa) is determined based on the Fl delays (DU-CU delay and CU-DU delay also being referred to as (Fl) UL and (Fl) DL delay respectively).
  • Fl delays DU-CU delay and CU-DU delay also being referred to as (Fl) UL and (Fl) DL delay respectively.
  • the CU 7000 and DU nodes 6100, 6200 exchange a time stamp information as well as a packet age information.
  • An example of packet age information for the uplink (DU to CU) is the time it takes from packet creation in the UE until the packet is ready to be transmitted over the Fl interface.
  • An example of packet age information in the downlink (CU to DU) is the time it takes from packet reception at the CU (from Core
  • the receiving node can calculate not only the radio link delay but also the end to end packet delay (e.g. as packet age + link delay).
  • the UE may convey packet generation information to the one or the plurality of DUs.
  • the one or the plurality of DUs determines the packet age information and sends this information in addition to the timestamp information to the CU.
  • This information may be conveyed in an additional information element (e.g. with the same PDU type with the age data inserted into the timestamp information field).
  • a new PDU type is added to section 5.5.2 of TS 38.425.
  • PDU Types 0 and 1 are already used and the new PDU Type Latency Information may for example use the next available PDU Type which is 2.
  • the field that specifies the Latency Information may be of different sizes, if needed.
  • the size of the different Latency Information can either be predetermined and fixed or in another
  • one of the octets in the frame contains a Length Indicator as in the figure 3 example below. It may also be beneficial to add an octet following the Latency Information that determines a subtype of the information contained in the LI.
  • figure 3 below is only an example embodiment and that other combinations of data fields can also be used to convey the timestamp and latency related information.
  • One other alternative for the UL is to use the DL DATA DELIVERY STATUS (PDU Type 1) as defined in reference 1 section 5.5.2.2. using the Cause report flag and Cause value for signaling latency related information and alternatively by defining a new DD flag for the DL DATA DELIVERY STATUS (PDU Type 1) and in this way convey the information elements defined below.
  • a new PDU Type may be defined in a more generic way and be used for UL Data traffic.
  • Such PDU Type may carry the latency information from DU to CU.
  • PDU Type may contain the timestamp for the transmission of UL PDUs, i.e. the timestamp set by the DU at the time an UL PDU is transmitted.
  • the new PDU may also contain the DL delay calculated by the DU by means of receiving DL PDU transmission timestamps from the CU.
  • the PDU Type 0 may be used to convey to the DU the UL delay estimated by the CU upon reception of the UL PDU transmission timestamp.
  • PDU Type 1 also known as DDDS.
  • DDDS DL estimated delay
  • the DDDS can be used to signal an average DL delay to the CU.
  • PDU Type This field is already defined in TS 38.425 and currently two values are used: 0 which indicates DL user data and 1 which indicates DL delivery data. A new value, e.g. 2 could be used to indicate that the PDU contains the information outlined in this invention disclosure.
  • Latency Information This field indicates if the data contained pertains to delay, timestamp information or some other information type.
  • the latency subtype is used to indicate what type of timestamp or delay information is contained in the PDU, e.g. if the data pertains to the UL or DL, if it is in timestamp information, e.g. Unix time (also known as POSIX time or UNIX Epoch time) or Internet Control Message Protocol (ICMP), estimated uplink latency or estimated downlink latency etc. for different time periods, e.g. per ls, lOs, 1 min, lh, session average etc.
  • timestamp information e.g. Unix time (also known as POSIX time or UNIX Epoch time) or Internet Control Message Protocol (ICMP), estimated uplink latency or estimated downlink latency etc. for different time periods, e.g. per ls, lOs, 1 min, lh, session average etc.
  • LI bit The LI bit is used to indicate the presence of a length indicator in the following octet.
  • Length Indicator This field is used to indicate length of the PDU in case this is not predetermined.
  • Fig. 4 shows an exemplary PDU information element that may be added to current 3GPP document TS 38.425, version 15.0.0. In such amendment, Fig. 3 may form Figure 5.2.2.X sub-titled with“Latency Information (PDU Type 2)”.
  • the PDU Type indicates the structure of the NR user plane frame.
  • the field takes the value of the PDU Type it identifies; i.e. "0" for PDU Type 0.
  • the PDU type is in bit 4 to bit 7 in the first octet of the frame.
  • the latency information may be conveyed in any available PDU Type sent from any 5G/NR node to another, either in UL or DL, and PDU type 2 is just an example. Further, as another non-limiting example, the latency information PDU could be sent from a gNB-DU to a gNB-CU or from a gNB-DU to an LTE eNB or from an LTE eNB to a gNB- CU.
  • Latency Information Subtype Description This field defines the sub type to the LATENCY INFORMATION PDU Type defined in section 5.5.3.1.
  • the spare field is set to "0" by the sender and should not be interpreted by the receiver. This field is reserved for later versions.
  • This parameter indicates if there is an octet containing a frame length indicator following the frame header.
  • the spare extension field shall not be sent.
  • the receiver should be capable of receiving a spare extension.
  • the spare extension should not be interpreted by the receiver, since in later versions of the present document additional new fields might be added in place of the spare extension.
  • the spare extension can be an integer number of octets carrying new fields or additional information; the maximum length of the spare extension field (m) depends on the PDU type.
  • Fig. 6 is a block diagram illustrating a gNB distributed unit DU node 6100 or 6200 according to some embodiments disclosed herein.
  • DU node 6100 may include processor 603 coupled with transceiver 601, network interface 605, and memory 607.
  • Transceiver 601 may include one or more of a cellular radio access network (RAN) interface (also referred to as a RAN transceiver) and/or another wireless network communication interface.
  • RAN radio access network
  • DU node 6100 can thus provide wireless communication over one or more radio links with one or more mobile communication devices.
  • RAN radio access network
  • Network interface 605 may provide communication with other network nodes/devices such as an gNB central unit CU node (e.g., CU node, gNB-CU, etc.), for example, over an Fl interface.
  • Processor 603 (also referred to as a processor circuit or processing circuitry) may include one or more data processing circuits, such as a general purpose and/or special purpose processor (e.g., microprocessor and/or digital signal processor).
  • Processor 603 may be configured to execute computer program instructions from functional modules in memory 607 (also referred to as a memory circuit or memory circuitry), described below as a computer readable medium, to perform some or all of the operations and methods that are described herein for one or more of the embodiments.
  • processor 603 may be defined to include memory so that separate memory 607 may not be required.
  • operations of DU node 6100 may be performed by processor 603, network interface 605, and/or transceiver 601.
  • processor 603 may control transceiver 601 to transmit downlink communications through transceiver 601 over a radio interface to one or more UEs and/or to receive uplink communications through transceiver 601 from one or more UEs over a radio interface.
  • processor 603 may control network interface 605 to transmit communications through network interface 605 to one or more other network nodes (e.g., to a CU node) and/or to receive communications through network interface 605 from one or more other network nodes (e.g., a CU node).
  • modules may be stored in memory 607, and these modules may provide instructions so that when instructions of a module are executed by processor 603, processor 603 performs respective operations (e.g., operations discussed below with respect to Example
  • the DU node 6100 and 6200 may be collocared in one physical node or may each constitute separate physical nodes.
  • one ore a plurality of DU nodes 6100 and 6200 may be collocated with CU node 7000 in one physical node, or may each constitute separate physical nodes.
  • Fig. 7 is a block diagram illustrating a gNB central unit CU node 7000 according to some embodiments disclosed herein.
  • CU node 7000 may include processor 703 coupled with network interface 701 and memory 705.
  • Network interface 701 may provide
  • Processor 703 may include one or more data processing circuits, such as a general purpose and/or special purpose processor (e.g., microprocessor and/or digital signal processor).
  • Processor 703 may be configured to execute computer program instructions from functional modules in memory 705 (also referred to as a memory circuit or memory circuitry), described below as a computer readable medium, to perform some or all of the operations and methods that are described herein for one or more of the embodiments.
  • processor 703 may be defined to include memory so that separate memory 705 may not be required.
  • operations of CU node 7000 may be performed by processor 703 and/or network interface 701.
  • processor 703 may control network interface 701 to transmit communications through network interface 701 to one or more other network nodes (e.g., to one or more DU nodes) and/or to receive communications through network interface 701 from one or more other network nodes (e.g., one or more DU nodes).
  • modules may be stored in memory 705, and these modules may provide instructions so that when instructions of a module are executed by processor 703, processor 703 performs respective operations (e.g., operations discussed below with respect to Example Embodiments).
  • CU node 700 may have a further network interface on a core NR network as discussed above.
  • Fig. 8 is a block diagram illustrating elements of a wireless device UE 3330 (also referred to as a wireless terminal, a wireless communication device, a wireless communication terminal, user equipment, UE, a user equipment node/terminal/device, etc.) configured to provide wireless communication according to embodiments of inventive concepts.
  • wireless device UE may include an antenna 3336, and a transceiver circuit 3337 (also referred to as radio interface) including a transmitter and a receiver configured to provide uplink and downlink radio communications with a base station (gNB) of a wireless communication network (also referred to as a radio access network RAN).
  • gNB base station
  • RAN wireless communication network
  • Wireless device UE may also include a processor circuit 3338 (also referred to as processing circuitry) coupled to the transceiver circuit, and a memory circuit 3335 (also referred to as memory) coupled to the processor circuit.
  • the memory circuit 3335 may include computer readable program code that when executed by the processor circuit 3338 causes the processor circuit to perform operations according to embodiments disclosed herein. According to other embodiments, processor circuit 3338 may be defined to include memory so that a separate memory circuit is not required.
  • Wireless device UE may also include an interface (such as a user interface) coupled with processor 3338, and/or wireless device UE may be an IoT and/or MTC device.
  • operations of wireless device UE may be performed by processor 3338 and/or transceiver 3337.
  • processor 3338 may control transceiver 3337 to transmit uplink communications through transceiver 3337 over a radio interface to a base station of a wireless communication network (e.g., a gNB base station including a gNB-CU and one or more gNB-DUs) and/or to receive downlink communications through transceiver 3337 from a base station (e.g., a gNB base station including a gNB-CU and one or more gNB- DUs) of the wireless communication network over a radio interface.
  • modules may be stored in memory 3335, and these modules may provide instructions so that when instructions of a module are executed by processor 3338, processor 3338 performs respective operations (e.g., operations discussed below with respect to Example Embodiments).
  • the invention may be especially beneficial in a cloud implementation (or virtualized environment), where the physical placement of the network nodes may not be transparent or may be at least partially unknown. Moreover, the physical placement of DU’s and CU’s may vary and the number of intermediate nodes may vary as well. As a consequence of this, the UL and DL delay characteristics will also show significant variations depending on configuration and distances; it may be beneficial to continuously measure the delay contributions of the UL and DL.
  • a communication system includes a telecommunication network 3210, such as a 3GPP-type cellular network, which comprises an access network 3211, such as a radio access network, and a core network 3214.
  • the access network 3211 comprises a plurality of base stations 3212a, 3212b, 3212c, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 32l3a, 32l3b, 32l3c.
  • Each base station 32l2a, 32l2b, 32l2c is connectable to the core network 3214 over a wired or wireless connection 3215.
  • a first user equipment (UE) 3291 located in coverage area 3213c is configured to wirelessly connect to, or be paged by, the corresponding base station 32l2c.
  • a second UE 3292 in coverage area 32l3a is wirelessly connectable to the corresponding base station 3212a. While a plurality of UEs 3291, 3292 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 3212.
  • the telecommunication network 3210 is itself connected to a host computer 3230, which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm.
  • the host computer 3230 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider.
  • the connections 3221, 3222 between the telecommunication network 3210 and the host computer 3230 may extend directly from the core network 3214 to the host computer 3230 or may go via an optional intermediate network 3220.
  • the intermediate network 3220 may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network 3220, if any, may be a backbone network or the Internet; in particular, the intermediate network 3220 may comprise two or more sub-networks (not shown).
  • the communication system of Fig. 9 as a whole enables connectivity between one of the connected UEs 3291, 3292 and the host computer 3230.
  • the connectivity may be described as an over-the-top (OTT) connection 3250.
  • the host computer 3230 and the connected UEs 3291, 3292 are configured to communicate data and/or signaling via the OTT connection 3250, using the access network 3211, the core network 3214, any intermediate network 3220 and possible further infrastructure (not shown) as intermediaries.
  • the OTT connection 3250 may be transparent in the sense that the participating communication devices through which the OTT connection 3250 passes are unaware of routing of uplink and downlink
  • a base station 3212 may not or need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 3230 to be forwarded (e.g., handed over) to a connected UE 3291. Similarly, the base station 3212 need not be aware of the future routing of an outgoing uplink communication originating from the UE 3291 towards the host computer 3230.
  • a host computer 3310 comprises hardware 3315 including a communication interface 3316 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the
  • the host computer 3310 further comprises processing circuitry 3318, which may have storage and/or processing capabilities.
  • the processing circuitry 3318 may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions.
  • the host computer 3310 further comprises software 3311, which is stored in or accessible by the host computer 3310 and executable by the processing circuitry 3318.
  • the software 3311 includes a host application 3312.
  • the host application 3312 may be operable to provide a service to a remote user, such as a UE 3330 connecting via an OTT connection 3350 terminating at the UE 3330 and the host computer 3310. In providing the service to the remote user, the host application 3312 may provide user data which is transmitted using the OTT connection 3350.
  • the communication system 3300 further includes a base station 3320 provided in a telecommunication system and comprising hardware 3325 enabling it to communicate with the host computer 3310 and with the UE 3330.
  • the base station 3320 may comprise a CU 7000 and one or a plurality of DUs 6000.
  • the hardware 3325 may include a communication interface 3326 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 3300, as well as a radio interface 3327 for setting up and maintaining at least a wireless connection 3370 with a UE 3330 located in a coverage area (not shown in Fig. 10) served by the base station 3320.
  • the communication interface 3326 may be configured to facilitate a connection 3360 to the host computer 3310.
  • connection 3360 may be direct or it may pass through a core network (not shown in Fig. 10) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system.
  • the hardware 3325 of the base station 3320 further includes processing circuitry 3328, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions.
  • the base station 3320 further has software 3321 stored internally or accessible via an external connection.
  • the communication system 3300 further includes the UE 3330 already referred to.
  • Its hardware 3335 may include a radio interface 3337 configured to set up and maintain a wireless connection 3370 with a base station serving a coverage area in which the UE 3330 is currently located.
  • the hardware 3335 of the UE 3330 further includes processing circuitry 3338, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions.
  • the UE 3330 further comprises software 3331, which is stored in or accessible by the UE 3330 and executable by the processing circuitry 3338.
  • the software 3331 includes a client application 3332.
  • the client application 3332 may be operable to provide a service to a human or non-human user via the UE 3330, with the support of the host computer 3310.
  • an executing host application 3312 may communicate with the executing client application 3332 via the OTT connection 3350 terminating at the UE 3330 and the host computer 3310.
  • the client application 3332 may receive request data from the host application 3312 and provide user data in response to the request data.
  • the OTT connection 3350 may transfer both the request data and the user data.
  • the client application 3332 may interact with the user to generate the user data that it provides.
  • the host computer 3310, base station 3320 and UE 3330 illustrated in Fig. 10 may be identical to the host computer 3230, one of the base stations 32l2a, 32l2b, 32l2c and one of the UEs 3291, 3292 of Fig. 9, respectively.
  • the inner workings of these entities may be as shown in Fig. 10 and independently, the surrounding network topology may be that of Fig. 9.
  • Network infrastructure may determine the routing, which it may be configured to hide from the UE 3330 or from the service provider operating the host computer 3310, or both. While the OTT connection 3350 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).
  • the wireless connection 3370 between the UE 3330 and the base station 3320 is in accordance with the teachings of the embodiments described throughout this disclosure.
  • One or more of the various embodiments improve the performance of OTT services provided to the UE 3330 using the OTT connection 3350, in which the wireless connection 3370 forms the last segment. More precisely, the teachings of these embodiments may improve the latency or power consumption and thereby provide benefits such as better responsiveness, extended battery lifetime.
  • a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve.
  • the measurement procedure and/or the network functionality for reconfiguring the OTT connection 3350 may be implemented in the software 3311 of the host computer 3310 or in the software 3331 of the UE 3330, or both.
  • sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 3350 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software 3311, 3331 may compute or estimate the monitored quantities.
  • the reconfiguring of the OTT connection 3350 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station 3320, and it may be unknown or imperceptible to the base station 3320.
  • measurements may involve proprietary UE signaling facilitating the host computer’s 3310 measurements of throughput, propagation times, latency and the like.
  • the measurements may be implemented in that the software 3311, 3331 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 3350 while it monitors propagation times, errors etc.
  • Fig. 11 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment.
  • the communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 9 and 10. For simplicity of the present disclosure, only drawing references to Fig. 11 will be included in this section.
  • the host computer provides user data.
  • the host computer provides the user data by executing a host application.
  • the host computer initiates a transmission carrying the user data to the UE.
  • the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure.
  • the UE executes a client application associated with the host application executed by the host computer.
  • Fig. 12 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment.
  • the communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 9 and 10. For simplicity of the present disclosure, only drawing references to Fig. 12 will be included in this section.
  • the host computer provides user data.
  • the host computer provides the user data by executing a host application.
  • the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure.
  • the UE receives the user data carried in the transmission.
  • Fig. 13 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment.
  • the communication system includes a host computer, a base station and a UE which may be those described with reference to Figs 9 and. For simplicity of the present disclosure, only drawing references to Fig. 13 will be included in this section.
  • the UE receives input data provided by the host computer.
  • the UE provides user data.
  • the UE provides the user data by executing a client application.
  • the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer.
  • the executed client application may further consider user input received from the user.
  • the UE initiates, in an optional third substep 3630, transmission of the user data to the host computer.
  • the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.
  • Fig. 14 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment.
  • the communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 9 and 10. For simplicity of the present disclosure, only drawing references to Fig. 14 will be included in this section.
  • the base station receives user data from the UE.
  • the base station initiates transmission of the received user data to the host computer.
  • the host computer receives the user data carried in the transmission initiated by the base station.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Environmental & Geological Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé mis en œuvre dans une unité centrale, CU (7000), d'une station de base, gNB (3320), pour déterminer un retard temporel vers une ou plusieurs unités distribuées, DU (6100, 6200), la CU mettant en place une interface vers un réseau radio central, CN, et chacune des DU mettant en place une interface radio vers un ou plusieurs UE, le procédé comportant les étapes consistant à: envoyer (S2) une première information de temps indicative d'un instant de transmission de paquets au niveau de la CU (7000) à une première DU (6100), recevoir (S4) une première information de retard de transmission DL associée à l'information de temps provenant de la première DU (6100), envoyer une seconde information de temps indicative d'un instant de transmission de paquets au niveau de la CU à une seconde DU (6200), recevoir une seconde information de retard de transmission DL associée à l'information de temps provenant de la seconde DU (6200), l'action étant basée sur la première et la seconde information de retard de transmission DL; l'invention concerne en outre un procédé mis en œuvre dans une DU (6100, 6200); l'invention concerne en outre des stations de base, un ordinateur hôte et un système de communication.
PCT/EP2019/058646 2018-04-06 2019-04-05 Gestion de latence de nœuds radio WO2019193154A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201862653864P 2018-04-06 2018-04-06
US62/653,864 2018-04-06

Publications (2)

Publication Number Publication Date
WO2019193154A1 true WO2019193154A1 (fr) 2019-10-10
WO2019193154A9 WO2019193154A9 (fr) 2020-03-19

Family

ID=66102115

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2019/058646 WO2019193154A1 (fr) 2018-04-06 2019-04-05 Gestion de latence de nœuds radio

Country Status (1)

Country Link
WO (1) WO2019193154A1 (fr)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210168637A1 (en) * 2020-02-14 2021-06-03 Jaemin HAN Support for quality-of-service (qos) monitoring in a dual connectivity or split ng-ran with control plane (cp) - user plane (up) separation
WO2021237487A1 (fr) * 2020-05-27 2021-12-02 Qualcomm Incorporated Appareil et procédé de communication sans fil utilisant des techniques à double connectivité
WO2022073473A1 (fr) * 2020-10-06 2022-04-14 Mediatek Singapore Pte. Ltd. Réduction de taux d'ack tcp dans des communications mobiles
WO2022093092A1 (fr) * 2020-10-26 2022-05-05 Telefonaktiebolaget Lm Ericsson (Publ) Équipement utilisateur, nœud de réseau radio et procédés pour gérer un délai dans un mode de double connexion
CN114641026A (zh) * 2022-02-17 2022-06-17 成都中科微信息技术研究院有限公司 一种提升NR系统中NG-RAN侧QoS监控精度的方法
CN114698027A (zh) * 2020-12-30 2022-07-01 千寻位置网络有限公司 消息处理方法及装置
EP4221374A4 (fr) * 2020-10-21 2023-11-22 Huawei Technologies Co., Ltd. Procédé et appareil de communication

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015192212A (ja) * 2014-03-27 2015-11-02 ソフトバンク株式会社 無線通信システムにおける基地局間ハンドオーバ方法
US20170238335A1 (en) * 2016-02-12 2017-08-17 Microelectronics Technology Inc. Method for radio source scheduling
US20170272975A1 (en) * 2015-05-22 2017-09-21 Ntt Docomo, Inc. User apparatus and base station

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015192212A (ja) * 2014-03-27 2015-11-02 ソフトバンク株式会社 無線通信システムにおける基地局間ハンドオーバ方法
US20170272975A1 (en) * 2015-05-22 2017-09-21 Ntt Docomo, Inc. User apparatus and base station
US20170238335A1 (en) * 2016-02-12 2017-08-17 Microelectronics Technology Inc. Method for radio source scheduling

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; Architecture description (Release 15)", 5 April 2018 (2018-04-05), XP051416509, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg%5Fran/WG3%5FIu/Draft%5FSpecs/TSG%2DRAN79/> [retrieved on 20180405] *
"3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; NR user plane protocol (Release 15)", 2 April 2018 (2018-04-02), XP051416502, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg%5Fran/WG3%5FIu/Draft%5FSpecs/TSG%2DRAN79/> [retrieved on 20180402] *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210168637A1 (en) * 2020-02-14 2021-06-03 Jaemin HAN Support for quality-of-service (qos) monitoring in a dual connectivity or split ng-ran with control plane (cp) - user plane (up) separation
US11838777B2 (en) * 2020-02-14 2023-12-05 Intel Corporation Support for quality-of-service (QOS) monitoring in a dual connectivity or split ng-ran with control plane (CP)—user plane (UP) separation
WO2021237487A1 (fr) * 2020-05-27 2021-12-02 Qualcomm Incorporated Appareil et procédé de communication sans fil utilisant des techniques à double connectivité
WO2022073473A1 (fr) * 2020-10-06 2022-04-14 Mediatek Singapore Pte. Ltd. Réduction de taux d'ack tcp dans des communications mobiles
EP4221374A4 (fr) * 2020-10-21 2023-11-22 Huawei Technologies Co., Ltd. Procédé et appareil de communication
WO2022093092A1 (fr) * 2020-10-26 2022-05-05 Telefonaktiebolaget Lm Ericsson (Publ) Équipement utilisateur, nœud de réseau radio et procédés pour gérer un délai dans un mode de double connexion
CN114698027A (zh) * 2020-12-30 2022-07-01 千寻位置网络有限公司 消息处理方法及装置
CN114641026A (zh) * 2022-02-17 2022-06-17 成都中科微信息技术研究院有限公司 一种提升NR系统中NG-RAN侧QoS监控精度的方法

Also Published As

Publication number Publication date
WO2019193154A9 (fr) 2020-03-19

Similar Documents

Publication Publication Date Title
US11695491B2 (en) 5G system support for conveying TSN time synchronization
WO2019193154A1 (fr) Gestion de latence de nœuds radio
CN106537846B (zh) 通信系统
US11864139B2 (en) Transmitting device, receiving device and methods performed therein for handling communication
EP3785475B1 (fr) Manipulation de la version rrc dans une station de base divisee
WO2014043665A2 (fr) Auto-optimisation de ressources radio de liaison terrestre et estimation de délai de liaison terrestre de petite cellule
KR102535036B1 (ko) Pdcp 복제의 트리거링이 제어되는 nr 사용자 평면 시그널링
US20230189045A1 (en) Latency management in integrated access and backhaul networks
US20230171014A1 (en) Technique for determining radio device residence time and scheduling
EP4165915B1 (fr) Technique de transport d&#39;un message de protocole de temps pour une mise en réseau sensible au temps
US20240214100A1 (en) Input Synchronization for Cyclic Queueing and Forwarding (CQF)
CN114070442A (zh) 不同通信方向上的呈现时间偏移量的自动对齐
WO2022150004A1 (fr) Procédé de traitement de mesures de qualité d&#39;expérience (qoe) pour des applications sensibles au temps dans un réseau de communication sans fil
CN115278713A (zh) 一种时延处理方法、装置及网络节点
WO2023234816A1 (fr) Procédé de gestion de communication de données par fourniture d&#39;une indication d&#39;un temps de livraison requis (dt) à un paquet
CN115707081A (zh) 定时同步方法、装置及存储介质

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: 19716399

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19716399

Country of ref document: EP

Kind code of ref document: A1