Minimizing drive test configuration in user equipment
The UE resolves conflicts by selecting or ensuring a single active configuration for multiple UL PDCP packet average delay configurations from different network nodes, adhering to 3GPP standards and maintaining network performance in dual connectivity.
Patent Information
- Application Number
- JP2024529269
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2021-12-02
- Filing Date
- 2022-11-28
- Publication Date
- 2026-02-27
- Estimated Expiration
- 2042-11-28
AI Technical Summary
Existing 3GPP standards prevent a UE from receiving multiple UL PDCP packet average delay configurations for one type of bearer, but recent developments have allowed scenarios where both the MN and SN configure the UE, leading to conflicts and violations of standardized procedures.
A UE receives multiple UL PDCP packet average delay configurations for the same type of bearer from different network nodes, selecting one configuration or ensuring only one configuration per bearer type is active, thereby resolving conflicts and adhering to 3GPP standards.
The solution allows the UE to collect and report measurements without conflicting configurations, ensuring compliance with 3GPP standards and maintaining network performance in dual connectivity scenarios.
Smart Images

Figure 0007821884000001 
Figure 0007821884000002 
Figure 0007821884000003
Abstract
Description
[Technical Field]
[0001] The present disclosure relates to techniques for minimizing drive test configurations in user equipment. [Background technology]
[0002] The fifth-generation (5G) radio access network (RAN) architecture, referred to as the Next-Generation Radio Access Network (NG-RAN), is shown in Figure 1. The NG-RAN shown in Figure 1 consists of a set of next-generation network nodes (gNBs) connected to the 5G Core (5GC) via an NG interface. The gNBs can support frequency division duplexing (FDD), time division duplexing (TDD), or dual-mode operation. The gNBs consist of a gNB centralized unit (gNB-CU) and a gNB distributed unit (gNB-DU). The gNB-CU and gNB-DU are connected via the F1 logical interface. Typically, one gNB-DU is connected to only one gNB-CU. However, for resiliency, with appropriate implementation, one gNB-DU can be connected to multiple gNB-CUs. NG, Xn, and F1 are logical interfaces.
[0003] The NG-RAN is layered into the Radio Network Layer (RNL) and the Transport Network Layer (TNL). The NG-RAN architecture, i.e., the NG-RAN logical nodes and the interfaces between them, are defined as part of the RNL. Each NG-RAN interface (NG, Xn, F1, etc.) specifies the associated TNL protocols and functions. The TNL provides services for user plane transport and signaling transport.
[0004] A gNB can also connect to a Long Term Evolution (LTE) evolved Node B (eNB) via the X2 interface. Another architecture option is for an LTE eNB connected to an Evolved Packet Core (EPC) network to connect via the X2 interface with a so-called NR-gNB. An NR-gNB is a gNB that is not directly connected to the core network (CN) and is connected to an eNB via X2 for the sole purpose of performing dual connectivity.
[0005] The architecture in Figure 1 can be extended by splitting the gNB-CU into two entities: the first, called gNB-CU-UP, provides the user plane (UP) and hosts the Packet Data Convergence Protocol (PDCP); the second, called gNB-CU-CP, provides the control plane (CP) and hosts the PDCP and Radio Resource Control (RRC) protocols; and the gNB-DU, which hosts the Radio Link Control (RLC), Medium Access Control (MAC), and Physical Layer (PHY) protocols.
[0006] Minimized Drive Testing (MDT) is a standardized mechanism to provide operators with network performance optimization tools. There are two MDT functions: immediate MDT and logged MDT. Immediate MDT involves measurements performed by the UE in the CONNECTED state and refers to the MDT function reporting measurements to the RAN available at the time of the reporting state, as well as measurements by the network for MDT purposes. Logged MDT involves the UE recording measurements for later reporting. More details can be found in the 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 37.320 version 16.6.0.
[0007] The Instant MDT is standardized to allow management systems to collect key performance indicators (KPIs) related to UEs in connected mode. The following excerpt from TS37.320 version 16.6.0 provides information on configuring and reporting measurements in Instant MDT.
[0008] 5.1.2.1 Measurement configuration Immediate MDT allows for the configuration of RAN and UE measurements, which are configured and reported based on existing RRC measurement procedures, with some extensions for location information. NOTE: In immediate MDT, no extensions related to timestamps are expected, i.e. timestamps are expected to be provided by the eNB / RNC / gNB. If the MDT configuration provided to the RAN includes an area scope, the UE will be configured with the respective measurements when it is connected to a cell that is part of the configured area scope. 5.1.2.2 Measurement report For Immediate MDT, the UE provides detailed location information (e.g., GNSS location information) if available. The UE also provides available neighbor cell measurement information that can be used to determine the UE's location (RF fingerprint). It is assumed that the ECGI, Cell-Id, or CellIdentity of the serving cell where the measurements are made are always known in E-UTRAN, UTRAN, or NR, respectively. The location information associated with the UE radio measurements for MDT can be correlated with other MDT measurements (e.g., RAN measurements). In the case of MDT measurements where the UE location information is provided separately, it is assumed that the correlation between the location information and the MDT measurements is performed based on timestamps in the TCE. 5.2.1.1 Immediate MDT Measurement and Reporting Triggers Measurements performed for immediate MDT purposes include reporting triggers and criteria used for RRM. MDT-specific UE-based measurements of UL PDCP delay are applied for QoS verification purposes. In addition, there are measurements performed at the eNB.
[0009] The same technical specification contains corresponding disclosures regarding next generation wireless access.
[0010] The following measurements are relevant for the disclosure (a detailed list is given in TS37.320 version 16.6.0): M6 packet delay measurements are performed per Data Radio Bearer (DRB) per UE separately in DL and UL. For M6, the measurement collection trigger can be the end of the measurement collection period.
[0011] Also relevant to the present disclosure is MDT for Multi-RAT Dual Connectivity (MR-DC). The following excerpt from TS37.320 version 16.6.0 provides information regarding instant MDT for MR-DC:
[0012] 5.4.1.3 MR-DC Instant MDT In signaling-based immediate MDT, the AMF provides the MDT configurations of both the MN and the SN, including the multi-RAT SN configuration (especially the E-UTRA and NR MDT configurations), to the MN. The MN then forwards the NR MDT configuration to the SN (in the EN-DC scenario, the SN is always NR). In management-based immediate MDT, OAM provides MDT configuration independently for both MN and SN. For both MN and SN, management-based MDT should not override signaling-based MDT. In immediate MDT configuration, the MN and SN can independently configure and receive measurements from the UE.
[0013] RAN internal latency can be split into several components, which are captured in TS38.314 version 16.4.0. The following excerpt from TS38.314 version 16.4.0 provides details of these components that make up RAN latency:
[0014] DL packet delay measurements, i.e., D1 (over-the-air interface DL delay), D2 (gNB-DU DL delay), D3 (F1-U DL delay), and D4 (CU-UP DL delay), need to be measured per DRB per UE.
[0015] The RAN part of the UL packet delay measurement (including the UE) is configured as follows: -D1 (UL PDCP packet mean delay time as defined in 4.3.1.1). -D2.1 (average packet delay for the over-the-air interface as defined in 4.2.1.2.2). -D2.2 (Average RLC Packet Delay as defined in 4.2.1.2.3). -D2.3 (mean delay UL of F1-U, measured using the same metric as mean delay DL of F1-U defined in clause 5.1.3.3.2 of TS28.552 [4]). -D2.4 (Average PDCP Reorder Delay as defined in 4.2.1.2.4).
[0016] The UL packet delay measurements, i.e., D1 (UL PDCP packet mean delay), D2.1 (over-the-air interface packet mean delay), D2.2 (RLC packet mean delay), D2.3 (UL mean delay over F1-U), and D2.4 (PDCP reordering mean delay), shall be measured per UE per DRB. The units of D1, D2.1, D2.2, D2.3, and D2.4 are 0.1 ms.
[0017] In the case of non-CU-DU split, the RAN part of the packet delay excludes the delay at the FI-U interface, i.e., D2.3 and D3.
[0018] In QoS monitoring of TS23.501[4], the RAN notifies the CN of the RAN part of the UL packet delay measurements, or the RAN part of the DL packet delay measurements, or both.
[0019] The formula for calculating D1 (average UL PDCP packet delay) is given in TS38.314 version 16.4.0.
[0020] In MR-DC, from the UE's perspective, there are three bearer types: Master Cell Group (MCG) bearer, Secondary Cell Group (SCG) bearer, and split bearer. These three bearer types are shown in Figure 2 for MR-DC using EPC (EN-DC) and in Figure 3 for MR-DC using 5GC (NGEN-DC, NE-DC, NR-DC).
[0021] In an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (E-UTRA) connected to an EPC, if the UE supports EN-DC, the network can configure either E-UTRA PDCP or NR PDCP for Master Node (MN) terminated MCG bearers, regardless of whether EN-DC is configured. Changing from E-UTRA to NR PDCP or vice versa can be performed via a reconfiguration procedure (with or without handover) using DRB release and addition or using the full configuration option.
[0022] In MR-DC with 5GC, NR PDCP is always used for all bearer types.
[0023] NGEN-DC is a dual connectivity configuration using 5GC, where the MN is a 4G NG-eNB and the secondary node (SN) is a 5G gNB. In NGEN-DC, the MN uses E-UTRA RLC / MAC and the SN uses NR RLC / MAC.
[0024] In NE-DC, NR RLC / MAC is used in the MN and E-UTRA RLC / MAC is used in the SN. In NR-DC, NR RLC / MAC is used in both the MN and SN.
[0025] From the network perspective, each bearer (MCG, SCG, and split bearer) can be terminated at the MN or the SN. The network-side protocol termination options are shown in Figure 4 for MR-DC with EPC (EN-DC) and in Figure 5 for MR-DC with 5GC (NGEN-DC, NE-DC, NR-DC).
[0026] Even if a UE is configured with only SCG bearers, logical channels are always configured in the MCG at least for signaling radio bearer 1 (SRB1) and signaling radio bearer 2 (SRB2).
[0027] If only MCG bearers are configured in the UE, i.e., even if no SCG is configured, it is considered to be MR-DC configured if at least one bearer is terminated in the SN.
[0028] Because the network relies on many Radio Resource Management (RRM) measurements from the UE to perform its functions, a framework for collecting RRM measurements is defined in 3GPP TS38.331 version 16.6.0. An excerpt from section 5.5.2.1 of this standard illustrates the relevant aspects regarding uplink delay configuration:
[0029] The network applies the following procedures: Use -ul-DelayValueConfig;dure to configure up to one measurement ID per CG:
[0030] 3GPP has discussed the measurement of UL PDCP packet average delay in MR-DC scenarios and agreed that the bearer terminating node (MN in case of MN terminated MCG / SCG / split bearer, SN in case of SN terminated MCG / SCG / split bearer) can configure the UE with the D1 measurements.
[0031] In management-based instantaneous MDT, the Operation, Administration and Maintenance (OAM) domain or system provides MDT configuration to target RAN nodes within an area scope. Each RAN node collects measurements according to the MDT configuration provided by the OAM and forwards the results to the OAM or Trace Collection Entity (TCE). Summary of the Invention
[0032] Currently, certain challenges exist. In particular, while the 3GPP standard specifies that a UE must not receive multiple UL PDCP packet average delay configurations for one type of bearer, recent developments have made such a scenario possible. For example, consider a scenario in which a UE is in MR-DC and OAM configures both the UE's MN and the UE's SN to collect UL PDCP packet average delay measurements. Both the MN and SN can select the UE for which D1 measurements are collected. The MN can configure the UE with ul-DelayValueConfig for both MCG and SCG bearers terminated at the MN. Meanwhile, the SN can configure the same UE with ul-DelayValueConfig for both MCG and SCG bearers terminated at the SN. However, this violates the currently standardized procedure, which allows a UE to be configured with only one PDCP queuing delay measurement per cell group (CG). As mentioned above, 3GPP TS38.331 version 16.6.0 specifies that the network "configures a maximum of one measurement ID per CG using reporting configuration with ul-DelayValueConfig", so the UE may receive conflicting configurations.
[0033] Certain aspects of the present disclosure and embodiments thereof may provide solutions to these and other problems.
[0034] According to a first aspect, there is provided a method in a user equipment (UE), the method including receiving a first MDT (Minimized Drive Test) configuration for measurements on a first Data Radio Bearer (DRB) of a first DRB type from a first network node, receiving a second MDT configuration for measurements on a second DRB of the first DRB type from a second network node, and reporting a plurality of measurement reports.
[0035]
[0013] Also provided is an apparatus for performing the method according to the first aspect. For example, a further aspect provides a UE, comprising: processing circuitry configured to cause the user equipment to receive, from a first network node, a first MDT configuration associated with measurements for a first DRB of a first DRB type, receive, from a second network node, a second MDT configuration associated with measurements for a second DRB of the first DRB type, and report a plurality of measurement reports.
[0036] According to a second aspect, a method in a user equipment (UE) is provided, the method including receiving a first MDT (Drive Test Minimization) configuration associated with measurements of a first data radio bearer (DRB) type, and receiving a second MDT configuration associated with measurements of the first DRB type, the method further including selecting one of the first MDT configuration and the second MDT configuration, and reporting according to the selected MDT configuration.
[0037] According to a third aspect, there is provided a user device configured to perform a method according to an embodiment of either the first or second aspect.
[0038] According to a fourth aspect, there is provided a method in a first network node for a user equipment (UE) operating in dual connectivity with the first network node and at least a second network node, the method comprising: determining, based on a DRB type of a first data radio bearer (DRB), whether to configure the UE to report measurements of the first DRB in accordance with a first minimized driven test (MDT) configuration.
[0039] According to a fifth aspect, there is provided a computer program product including a computer readable medium having computer readable code embodied therein, the computer readable code being configured, when executed by a suitable computer or processor, to cause the computer or processor to perform a method of any of the embodiments according to the first or second aspects.
[0040] According to a sixth aspect, there is provided a computer program product including a computer readable medium having computer readable code embodied therein, the computer readable code being configured, when executed by a suitable computer or processor, to cause the computer or processor to perform the method of any of the embodiments according to the fourth aspect.
[0041] According to a seventh aspect, there is provided a first network node configured to perform a method according to any embodiment of the fourth aspect.
[0042] According to an eighth aspect, there is provided a user apparatus comprising a processor and a memory, the memory comprising instructions executable by the processor, whereby the apparatus is operable to perform a method according to an embodiment of either the first or second aspect.
[0043] According to a ninth aspect, there is provided a first network node comprising a processor and a memory, the memory comprising instructions executable by the processor, whereby the apparatus is operable to perform a method according to any embodiment of the fourth aspect.
[0044] Therefore, the technology disclosed herein provides a solution to the above-mentioned problem. In some embodiments, the disclosed technology provides a mechanism by which a UE can select an applicable configuration in a situation where the UE receives multiple MDT configurations for the same radio data bearer type. The disclosed technology further provides a mechanism to prevent the UE from receiving multiple MDT configurations for the same radio data bearer type from the same network node. Thus, conflicts are avoided within communication networks operating in accordance with 3GPP standards. [Brief explanation of the drawings]
[0045] Some of the embodiments contemplated herein will now be described in more detail with reference to the accompanying drawings, in which:
[0046] [Figure 1] Shows the 5G RAN architecture. [Figure 2] The radio protocol architecture for MCG, SCG and split bearer is shown from the UE perspective in MR-DC with EPC. [Figure 3] This figure shows the radio protocol architecture of MCG, SCG and split bearer in MR-DC with 5GC from the UE perspective. [Figure 4] 1 shows the network side protocol termination options for MCG, SCG and split bearer in MR-DC with EPC. [Figure 5] Shows network side protocol termination options for MCG, SCG and split bearer in MR-DC with 5GC. [Figure 6] FIG. 1 is a schematic diagram showing an OAM, a MN, a SN, and a UE. [Figure 7] 1 is a flowchart illustrating a method performed by a user device, according to some embodiments. [Figure 8] 10 is a flow chart illustrating a method performed by a user device according to a further embodiment; [Figure 9] 10 is a flowchart illustrating a method performed by a first network node according to a further embodiment; [Figure QQ1] 1 illustrates an example of a communication system according to some embodiments. [Figure QQ2] 1 illustrates a UE according to some embodiments. [Figure QQ3] 1 illustrates a network node according to some embodiments. [Figure QQ4] FIG. 2 is a block diagram of a host. [Figure QQ5] FIG. 1 is a block diagram illustrating a virtualization environment in which functionality implemented by some embodiments may be virtualized. [Figure QQ6] 1 is a communication diagram of a host communicating with a UE via a network node over a partial wireless connection, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION
[0047] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings, in which: The embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.
[0048] As previously mentioned, the 3GPP standard specifies that a UE is not allowed to receive multiple UL PDCP packet average delay configurations for one type of bearer. However, recent agreements within 3GPP have allowed such scenarios to arise, such as when both the MN and SN of a UE receive MDT configurations to collect UL PDCP packet average delay measurements. This issue is further illustrated in Figure 6.
[0049] Figure 6 shows a schematic of the OAM, MN, SN, and UE. The MN is shown to include an MN-CU-CP, an MN-CU-UP, and an MN-DU. The SN is shown to include an SN-CU-CP, an SN-CU-UP, and an SN-DU.
[0050] The OAM sends the MDT configuration with M6 measurements to the MN and SN (M6 measurements are defined above and in 3GPP TS37.320 version 16.6.0). The following steps are then performed: In step 1, the MN configures the MN terminated MCG bearer. In step 2, labeled (2), the SN configures the SN terminated MCG bearer. In step 3.1 (labeled (3.1)), the MN-CU-CP configures the UE with D1 measurement configuration for the MN terminated MCG bearer (D1 measurements are also defined above). In step 3.2 (labeled (3.2)), the SN-CU-CP configures the UE with D1 measurement configuration for the SN terminated MCG bearer.
[0051] Therefore, the UE will receive two D1 measurement configurations for the MCG cell, which violates the expected way of operation of MDT according to the 3GPP standard. The same situation can occur, for example, if the UE is configured with an SN-terminated SCG bearer and an MN-terminated SCG bearer.
[0052] The present disclosure proposes a solution to the above problem.
[0053] In some embodiments, a UE can receive multiple UL PDCP packet average delay configurations for one type of bearer, but cannot receive multiple UL PDCP packet average delay configurations for one type of bearer from one node. In other words, if the configurations are for the same type of bearer, they must be from different network nodes. Thus, according to some embodiments, a method is provided that is performed by a wireless terminal (or UE) to receive multiple UL PDCP packet average delay measurement configurations for the same type of bearer (e.g., MCG bearer, SCG bearer), each received from a different node in the network. In these embodiments, the UE collects and reports multiple measurement reports.
[0054] In alternative embodiments, the UE receives multiple D1 measurement configurations associated with the same bearer type from the same network node. In these embodiments, the UE selects one measurement configuration for the bearer type. For example, the UE may select the most recently received configuration or the first received configuration. The UE then reports according to the selected MDT configuration.
[0055] The terms wireless terminal, wireless device, terminal device, and UE are used interchangeably herein, as are the terms wireless network, network node, network, base station, and RAN node.
[0056] An example of the proposed method performed by a user device includes: 1) receiving at least one MDT configuration related to delay measurement from a network node, for example, the MDT configuration for configuring the UE to perform UL PDCP packet average delay measurement; 2) Identify multiple MDT configurations available for the same bearer type. 3) Collect UL PDCP packet delay measurements for each cell group (e.g., each DRB type). 4) Report the measurement results to the network.
[0057] The method further incorporates a procedure performed by a network node to configure a wireless terminal (or UE) to measure UL PDCP packet average delay measurements. According to some embodiments, the method in the network node includes: 1) Receive an MDT configuration related to delay measurements, which can be received from an OAM or core network node. 2) Identify the type of bearer configuration configured for the UE in the MDT configuration. The bearer configuration can be, for example, an MCG bearer, an SCG bearer, an SN-terminated MCG bearer, an MN-terminated SCG bearer, an MN-terminated split bearer, or an SN-terminated split bearer. 3) Determine whether to configure the UE according to the MDT configuration. If it is determined to configure the UE, the method also includes configuring the UE to report a UL PDCP packet average delay measurement (e.g., a D1 measurement) according to the MDT configuration. In some embodiments, a single node may provide only one UL PDCP packet average delay configuration for a given bearer type (i.e., DRB type). The DRB type may be, for example, an MCG bearer, an SCG bearer, or a split bearer. Thus, the average delay measurement may be determined based on the type of DRB to which it is associated, as identified in step 2. 4) Receive one or more measurement reports from the UE. The measurement report may include a delay measurement. For example, the measurement report may include a UL PDCP packet average delay measurement, such as a D1 measurement.
[0058] Each step of the method performed by the user equipment will now be described in more detail with reference to various specific embodiments, in which the UE is operating in dual connectivity with a MN and at least one SN.
[0059] receiving, from a network node, an MDT configuration for performing PDCP packet average delay measurements in the UL; In this step, the UE receives an MDT configuration from the network node to perform UL PDCP packet average delay measurements (eg, D1 measurements).
[0060] Identifying the availability of multiple MDT configurations for the same bearer type The UE identifies that multiple D1 measurement configurations exist for the same bearer type.
[0061] In some embodiments, there is only one MDT configuration for a given bearer type from a given network node.
[0062] In other embodiments, there may be multiple MDT configurations for a given bearer type from a given network node. In some of these embodiments, if there are multiple D1 measurement configurations associated with the same bearer type from the same network node, the UE applies the most recent configuration. Alternatively, the UE may apply the configuration that the UE received first. For example, if the UE receives a second D1 measurement configuration for a cell group already configured with a first D1 measurement configuration, the UE rejects the second D1 configuration. The UE may inform the network node that it is already configured with a D1 measurement configuration.
[0063] Collect average latency measurements for PDCP packets on the UL for each bearer type The UE collects UL PDCP average packet delay measurements separately for each bearer type. The DRB type can be, for example, MCG bearer, SCG bearer, or split bearer. If there are multiple MDT configurations for a given bearer type from a given network node, the UE selects one of them.
[0064] Reports measurement reports to the network The UE reports the collected measurements to each of the constituent nodes in the network.
[0065] As mentioned above, the disclosed technology further incorporates procedures performed by a network node to configure a wireless terminal (or UE) to measure UL PDCP packet average delay measurements. These procedures are now described in more detail.
[0066] Receive MDT configuration related to delay measurements The RAN node receives an MDT configuration for performing delay measurements. The MDT configuration can be received, for example, from another network node, an OAM, or a core network node. The MDT configuration may include M6 measurements. The RAN node identifies that part of the delay measurement configuration (i.e., UL PDCP packet average delay measurements, i.e., D1 measurements) needs to be collected from the UE.
[0067] Identify the type of bearer configuration configured in the UE Upon receiving the configuration, the RAN node identifies the type of bearer (Data Radio Bearer, DRB) configured for the UE, along with the PDCP termination point of the bearer. The DRB type may be, for example, an MCG bearer, an SCG bearer, or a split bearer. The termination point of the bearer may be a master node or a secondary node.
[0068] Configure the UE to calculate uplink PDCP packet average delay measurements The network node configures the UE to collect the UL PDCP packet average delay.
[0069] In some embodiments, the network allows a node to provide a UE with only one UL PDCP average packet delay configuration for a given bearer type. Thus, if the network node identifies that the UE is already configured to report MDT measurements for a DRB of an identified DRB type, the network node does not configure the UE to report further measurements for DRBs of the same DRB type. Alternatively, the network node may unconfigure the UE from the existing configuration for the DRB before configuring the UE according to the most recently received MDT configuration.
[0070] receiving one or more measurement reports from the UE; After configuring the UE to report D1 measurements, the network node receives corresponding measurement reports from the UE related to the MDT configuration.
[0071] Therefore, according to the techniques disclosed herein, the UE can avoid the aforementioned conflict when operating in dual connectivity with a first network node and a second network node. The UE receives an MDT configuration from the network for calculating UL PDCP packet average delay measurements, collects the measurements, and reports them to the network.
[0072] 7 is a flowchart illustrating a method according to an embodiment of the present disclosure. The method may be performed by a user equipment (UE), such as the UE illustrated in FIG. 6, the UE QQ112A, QQ112B, QQ112C, or QQ112D described below with reference to FIG. QQ1, the UE QQ200 described below with reference to FIG. QQ2, or the UE QQ606 described below with reference to FIG. QQ6.
[0073] In some embodiments, the UE operates in dual connectivity with a first network node and at least a second network node. The first network node may be a master node for the UE. The second network node may be a secondary node for the UE. The second network node may be the only SN for the UE or one of multiple SNs. The first and / or second network node may be, for example, a gNB shown in FIG. 1, an SN shown in any of FIG. 4, FIG. 5, or FIG. 6, network node QQ110A or QQ110B shown in FIG. QQ1, network node Q300 shown in FIG. QQ3, or network node QQ604 shown in FIG. QQ6.
[0074] The method includes receiving, from a first network node, a first MDT configuration for measuring a first DRB having a first DRB type, in step 702. The first DRB type may be, for example, an MCG bearer, an SCG bearer, or a split bearer.
[0075] In step 704, the UE receives, from a second network node, a second MDT configuration related to measurements on a second DRB of the first DRB type (ie, the same DRB type as the first DRB).
[0076] In step 706, the UE reports a plurality of measurement reports, for example, measurements according to a first MDT configuration may be reported to a first network node and measurements according to a second MDT configuration may be reported to a second network node.
[0077] The first DRB type measurement (also referred to herein as an MDT measurement) may be a measurement for quantifying packet delay in a radio access network. In some embodiments, the measurement comprises an uplink (UL) Packet Data Convergence Protocol (PDCP) packet average delay measurement, also referred to as a D1 measurement. The measurement may follow an M6 measurement (a PDCP packet delay measurement per DRB per UE) configured in the first MDT configuration.
[0078] In step 708, optionally, the UE transmits an indication to the network node indicating that the UE is configured for the first DRB type according to both the first MDT configuration and the second MDT configuration.
[0079] In some embodiments, optionally, the method further includes receiving, in step 710, a third MDT configuration related to measurements for a third DRB of a second DRB type (e.g., different from the first DRB type). In step 712, the UE reports according to the third MDT configuration. In some embodiments, reporting according to the third MDT configuration comprises performing measurements for the third DRB according to the third MDT configuration and reporting results of the performed measurements. Thus, in these embodiments, the UE may collect and report measurements for each DRB type. The network may be configured to allow a single network node to provide only one UL PDCP packet average delay configuration for a given type of bearer (i.e., DRB).
[0080] The UE may perform the method of Figure 7 in response to executing appropriately designed computer-readable code. The computer-readable code may be embodied in or stored on a computer-readable medium, such as a memory chip, an optical disk, or other storage medium. The computer-readable medium may be part of a computer program product.
[0081] 8 is a flowchart illustrating a method according to a further embodiment. The method may be performed by a user equipment (UE), such as the UE illustrated in FIG. 6, the UE QQ112A, QQ112B, QQ112C, or QQ112D described below with reference to FIG. QQ1, the UE QQ200 described below with reference to FIG. QQ2, or the UE QQ606 described below with reference to FIG. QQ6.
[0082] In some embodiments, the UE operates in dual connectivity with a first network node and at least a second network node. The first network node may be a master node for the UE. The second network node may be a secondary node for the UE. The second network node may be the only SN for the UE or one of multiple SNs. The first and / or second network node may be, for example, a gNB shown in FIG. 1, an SN shown in any of FIG. 4, FIG. 5, or FIG. 6, network node QQ110A or QQ110B shown in FIG. QQ1, network node Q300 shown in FIG. QQ3, or network node QQ604 shown in FIG. QQ6.
[0083] The method includes, in step 802, receiving a first drive test minimization (MDT) configuration associated with measurements of a first data radio bearer (DRB) type, and, in step 804, receiving a second MDT configuration associated with measurements of the first DRB type.
[0084] The first DRB type measurement (also referred to herein as an MDT measurement) may be a measurement for quantifying packet delay in a radio access network. In some embodiments, the measurement comprises an uplink (UL) Packet Data Convergence Protocol (PDCP) packet average delay measurement, also referred to as a D1 measurement. The measurement may follow an M6 measurement (a PDCP packet delay measurement per DRB per UE) configured in the first MDT configuration.
[0085] The first DRB type is, for example, an MCG bearer, an SCG bearer, or a split bearer.
[0086] The method also includes, in step 806, selecting one of the first MDT configuration and the second MDT configuration, and, in step 808, reporting according to the selected MDT configuration.
[0087] In some embodiments, the first and second MDT configurations are received from different network nodes. For example, the first MDT configuration may be received from a first network node and the second MDT configuration may be received from a second network node. In some of these embodiments, selecting one MDT configuration includes selecting a most recently received MDT configuration. Alternatively, selecting one MDT configuration includes selecting an initially received MDT configuration. In further embodiments, selecting one MDT configuration may include determining that the UE is already configured according to the first MDT configuration for the first DRB type and selecting (i.e., maintaining) the first MDT configuration for the first DRB type. In these embodiments, the method may further include transmitting an indication to the network node that the UE is configured according to the first MDT configuration for the first DRB type.
[0088] In alternative embodiments, the first and second MDT configurations are received from the same network node. In some of these embodiments, selecting one MDT configuration includes selecting a most recently received MDT configuration. Alternatively, selecting one MDT configuration includes selecting an initially received MDT configuration. For example, selecting one MDT configuration may include determining that the UE is already configured according to the first MDT configuration for the first DRB type and selecting (i.e., maintaining) the first MDT configuration. In these embodiments, the method may further include transmitting an indication to the network node indicating that the UE is configured according to the first MDT configuration for the first DRB type.
[0089] In some embodiments, reporting in accordance with the selected MDT configuration includes performing measurements on the first DRB type in accordance with the selected MDT configuration and reporting results of the performed measurements. Reporting results of the performed measurements includes transmitting the results to a network node that transmitted the corresponding MDT configuration to the UE.
[0090] In some embodiments, the method further includes receiving a third MDT configuration associated with measurements of the second DRB type and reporting according to the third MDT configuration. In some embodiments, reporting according to the third MDT configuration includes performing measurements of the second DRB type according to the third MDT configuration and reporting results of the performed measurements. Thus, in these embodiments, the UE can collect and report measurements for each DRB type. In some of these embodiments, the UE cannot be configured to report measurements according to multiple MDT configurations for a given DRB type. The network may be configured to allow a single network node to provide only one UL PDCP average packet delay configuration for a given bearer type (i.e., DRB).
[0091] The UE may perform the method of Figure 8 in response to executing appropriately designed computer-readable code. The computer-readable code may be embodied in or stored on a computer-readable medium, such as a memory chip, an optical disk, or other storage medium. The computer-readable medium may be part of a computer program product.
[0092] FIG. 9 is a flowchart illustrating a method performed by a first network node according to a further embodiment.
[0093] The UE operates in dual connectivity with a first network node and at least a second network node. The first network node may be a master node configured for the UE or a secondary node configured for the UE. If the first network node is an SN, it may be the only SN configured for the UE or one of multiple SNs. The first network node may be, for example, the gNB shown in FIG. 1, the MN shown in any of FIG. 4, FIG. 5, or FIG. 6, the SN shown in any of FIG. 4, FIG. 5, or FIG. 6, the network node QQ110A or QQ110B described below with reference to FIG. QQ1, the network node Q300 described below with reference to FIG. QQ3, or the network node QQ604 described below with reference to FIG. QQ6.
[0094] The second network node may be a master node or a secondary node of the UE. If the second network node is an SN, it may be the only SN of the UE or one of multiple SNs. The second network node may be, for example, the gNB shown in FIG. 1, the MN shown in any of FIG. 4, FIG. 5, or FIG. 6, the SN shown in any of FIG. 4, FIG. 5, or FIG. 6, the network node QQ110A or QQ110B described below with reference to FIG. QQ1, the network node Q300 described below with reference to FIG. QQ3, or the network node QQ604 described below with reference to FIG. QQ6.
[0095] The method of FIG. 9 includes, in step 902, determining whether to configure the UE to report measurements of the first DRB according to a first drive test minimization (MDT) configuration based on a DRB type of the first DRB.
[0096] The DRB type is, for example, an MCG bearer, an SCG bearer, or a split bearer.
[0097] The first MDT configuration may include M6 measurements (PDCP packet delay measurements per DRB per UE).
[0098] The first DRB type measurement (also referred to herein as an MDT measurement) may be a measurement for quantifying packet delay in a radio access network. In some embodiments, the measurement includes an uplink (UL) Packet Data Convergence Protocol (PDCP) packet average delay measurement, also referred to as a D1 measurement. The measurement may be in accordance with an M6 measurement configured in the first MDT configuration.
[0099] In some embodiments, determining based on the DRB type includes determining whether the UE is already configured to report MDT measurements for DRBs of the same DRB type as the first DRB. In some of these embodiments, the first network node cannot configure the UE (or any UE) to report measurements according to multiple MDT configurations for a given DRB type.
[0100] The method may further include, in response to determining that the UE has an existing configuration for reporting measurements for a DRB of the same DRB type as the first DRB, determining not to configure the UE to report measurements for the first DRB in accordance with the first MDT configuration.
[0101] Alternatively, the method may include, in response to determining that the UE has an existing configuration reporting measurements for DRBs of the same DRB type as the first DRB, releasing the UE from the existing configuration and configuring the UE to report measurements for the first DRB in accordance with the first MDT configuration.
[0102] In some embodiments, the method includes, in response to determining that the UE does not have an existing configuration for reporting measurements for a DRB of the same DRB type as the first DRB, configuring the UE to report measurements for the first DRB in accordance with a first MDT configuration.
[0103] The method may further include receiving a first MDT configuration before determining whether to configure the UE to report the DRB measurements according to the first MDT configuration. The first MDT configuration may be received from an OAM or a core network node.
[0104] The first network node may perform the method of Figure 9 in response to execution of suitably formulated computer-readable code. The computer-readable code may be embodied in or stored on a computer-readable medium, such as a memory chip, an optical disk, or other storage medium. The computer-readable medium may be part of a computer program product.
[0105] FIG. QQ1 illustrates an example of a communication system QQ100 according to some embodiments.
[0106] In this example, communication system QQ100 includes a telecommunications network QQ102 including an access network QQ104, such as a radio access network (RAN), and a core network QQ106 including one or more core network nodes QQ108. Access network QQ104 includes one or more access network nodes, such as access network nodes QQ110a and QQ110b (one or more of which may be generally referred to as access network node QQ110), or some other similar 3GPP access node or non-3GPP access point. Access network node QQ110 facilitates direct or indirect connectivity of wireless devices (interchangeably referred to herein as user equipment (UE)), such as connecting UEs QQ112a, QQ112b, QQ112c, and QQ112d (one or more of which may be generally referred to as UEs QQ112) to core network QQ106 over one or more wireless connections. The access network node QQ110 may be, for example, an access point (AP) (e.g., a wireless access point), a base station (BS) (e.g., a radio base station, a Node B, an evolved Node B (eNB), and an NR Node B (gNB)).
[0107] Unless otherwise specified, the term "network node" refers to both the access network node QQ 110 and the core network node QQ 108.
[0108] Exemplary wireless communications over wireless connections include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for carrying information without the use of wires, cables, or other material conductors. Moreover, in various embodiments, communication system QQ100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals, whether via wired or wireless connections. Communication system QQ100 may include and / or interface with any type of communication, telecommunications, data, cellular, wireless network, and / or other similar types of systems.
[0109] The wireless device / UEQQ112 may be any of a wide variety of communication devices, including wireless devices, that are positioned, configured, and / or operable to communicate wirelessly with the network node QQ110 and other communication devices. Similarly, the access network node QQ110 is positioned, capable, configured, and / or operable to communicate, directly or indirectly, with the UEQQ112 and / or with other network nodes or equipment within the telecommunications network QQ102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as management, within the telecommunications network QQ102.
[0110] In the illustrated example, core network QQ106 connects access network node QQ110 to one or more hosts, such as host QQ116. These connections may be direct or indirect through one or more intermediate networks or devices. In other examples, a network node may be directly coupled to a host. Core network QQ106 includes one or more core network nodes (e.g., core network node QQ108) structured with hardware and software components. The functionality of these components may be substantially similar to that described with respect to wireless devices / UEs, access network nodes, and / or hosts, and therefore, these descriptions are generally applicable to the corresponding components of core network node QQ108. Exemplary core network nodes include one or more of a Mobile Switching Center (MSC), a Mobility Management Entity (MME), a Home Subscriber Server (HSS), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Subscription Identifier Deciphering Function (SIDF), a Unified Data Management (UDM), a Security Edge Protection Proxy (SEPP), a Network Publishing Function (NEF), and / or a User Plane Function (UPF).
[0111] Host QQ 116 may be owned or controlled by, and operated by or on behalf of, a non-operator service provider or provider of access network QQ 104 and / or telecommunications network QQ 102. Host QQ 116 may host a variety of applications to provide one or more services. Examples of such applications include the provision of live and / or pre-recorded audio / video content, data collection services such as acquiring and compiling data regarding various ambient conditions sensed by multiple UEs, analytics functionality, social media, functionality for controlling or otherwise interacting with remote devices, functionality for alarm and monitoring centers, or any other such functionality performed by a server.
[0112] Overall, the communication system QQ100 of FIG. QQ1 enables connectivity between wireless devices / UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as a particular standard, including, but not limited to, Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G), a wireless local area network (WLAN) standard, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (WiFi), and / or any other suitable wireless communication standard, such as Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC), ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standard, such as LoRa and Sigfox.
[0113] In some examples, the telecommunications network QQ102 is a cellular network that implements functions standardized by 3GPP. Thus, the telecommunications network QQ102 may support network slicing to provide different logical networks to different devices connected to the telecommunications network QQ102. For example, the telecommunications network QQ102 may provide Ultra-Reliable Low Latency Communication (URLLC) services to some UEs, enhanced Mobile Broadband (eMBB) services to other UEs, and massive machine-type communication (mMTC) / massive IoT services to additional UEs.
[0114] In some examples, the UE QQ 112 is configured to transmit and / or receive information without direct human interaction. For example, the UE may be designed to transmit information to the access network QQ 104 on a predetermined schedule, when triggered by an internal or external event, or in response to a request from the access network QQ 104. Additionally, the UE may be configured to operate in a single or multi-RAT or multi-standard mode. For example, the UE may be configured and operate in any one or combination of Wi-Fi, NR (New Radio), and LTE, i.e., for Multi-Radio Dual Connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio-Dual Connectivity (EN-DC).
[0115] In the example shown in FIG. 1, hub QQ114 communicates with access network node QQ104 to facilitate indirect communication between one or more UEs (e.g., UEs QQ112c and / or QQ112d) and access network nodes (e.g., access network node QQ110b). In some examples, hub QQ114 may be a controller, router, content source, analytics node, or any of the other communication devices described herein with respect to UEs. For example, hub QQ114 may be a broadband router that enables access to core network node QQ106 for UEs. As another example, hub QQ114 may be a controller that sends commands or instructions to one or more actuators within the UE. The commands or instructions may be received from the UE, network node QQ110, or may be accepted by executable code, scripts, processes, or other instructions within hub QQ114. As another example, hub QQ114 may be a data collector that acts as a temporary storage for UE data and, in some embodiments, may perform analysis or other processing of that data. As another example, Hub QQ 114 may be a content source. For example, for UEs that are VR headsets, displays, loudspeakers, or other media delivery devices, Hub QQ 114 may obtain media or data related to VR assets, video, audio, or other sensory information via a network node, and then provide it to the UE either directly or after performing local processing and / or adding additional local content. In yet another example, Hub QQ 114 acts as a proxy server or orchestrator for the UEs, particularly if one or more of the UEs are low-energy IoT devices.
[0116] Hub QQ114 may have a constant / permanent or intermittent connection to network node QQ110b. Hub QQ114 may also enable different communication schemes and / or schedules between hub QQ114 and UEs (UEs QQ112c and / or QQ112d) and between hub QQ114 and core network QQ106. In other examples, hub QQ114 is connected to core network QQ106 and / or one or more UEs via a wired connection. Moreover, hub QQ114 may be configured to connect to an M2M service provider over access network QQ104 and / or to other UEs over a direct connection. In some scenarios, a UE may establish a wireless connection with network node QQ110b while still being connected via hub QQ114 via a wired or wireless connection. In some embodiments, hub QQ 114 may be a dedicated hub, i.e., a hub whose primary function is to route communications between UEs and network node QQ 110b. In other embodiments, hub QQ 114 may be a non-dedicated hub, i.e., a device that is operable to route communications between UEs and network node QQ 110b, but that is additionally operable as a communications origination and / or termination point for any data channel.
[0117] Figure QQ2 illustrates a wireless device or UE QQ200 according to some embodiments. As used herein, UE refers to a device capable of, configured, arranged, and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of wireless devices / UEs include, but are not limited to, smartphones, mobile phones, cell phones, Voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, gaming consoles or devices, music storage devices, playback appliances, wearable terminal devices, wireless endpoints, mobile stations, tablets, laptops, laptop embedded equipment (LEE), laptop mounted equipment (LME), smart devices, wireless customer premises equipment (CPE), automotive or vehicle embedded / integrated wireless devices, etc. Other examples include any UE identified by 3GPP, including narrowband Internet of Things (NB-IoT) UEs, machine type communication (MTC) UEs, and / or enhanced MTC (eMTC) UEs.
[0118] A wireless device / UE may support device-to-device (D2D) communications, for example, by implementing 3GPP standards for sidelink communications, dedicated short-range communications (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2E). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the associated device. Instead, a UE may represent a device (e.g., a smart sprinkler controller) that is intended for sale to or operation by a human user, but that may not, at least initially, be associated with a particular human user. Alternatively, a UE may represent a device (e.g., a smart power meter) that is not intended for sale to or operation by an end user, but that may be associated with or operated for the benefit of a user.
[0119] The UE QQ200 includes a processing circuit QQ202, a power supply QQ208, a memory QQ210, a communication interface QQ212, and / or any other components operably coupled via a bus QQ204 to an input / output interface QQ206, or any combination thereof. A given UE may utilize all or a subset of the components shown in FIG. QQ2. The level of integration between components may vary from one UE to another. Furthermore, a given UE may include multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.
[0120] The processing circuit QQ202 is configured to process instructions and data and may be configured to implement any sequential state machine operable to execute instructions stored as a machine-readable computer program in memory QQ210. The processing circuit QQ202 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.), programmable logic with appropriate firmware, one or more stored computer programs, a general-purpose processor such as a microprocessor or digital signal processor (DSP) with appropriate software, or any combination of the above. For example, the processing circuit QQ202 may include multiple central processing units (CPUs). The processing circuit QQ202, alone or in combination with other UEQQ200 components, such as memory QQ210, may be operable to provide the functionality of UEQQ200. For example, the processing circuit QQ202 may be configured to cause UEQQ200 to perform a method such as that described with reference to FIG. 7 and / or FIG. 8.
[0121] In the above example, the input / output interface QQ206 may be configured to provide one or more interfaces for input devices, output devices, or one or more input / output devices. Examples of output devices include speakers, sound cards, video cards, displays, monitors, printers, actuators, emitters, smart cards, other output devices, or any combination thereof. An input device may enable a user to capture information from the UEQQ200. Examples of input devices include touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital video cameras, webcams, etc.), microphones, sensors, mice, trackballs, directional pads, trackpads, scroll wheels, and smart cards. A presence-sensitive display may include a capacitive or resistive touch sensor for sensing input from a user. The sensor may be, for example, an accelerometer, gyroscope, tilt sensor, force sensor, magnetic sensor, optical sensor, proximity sensor, biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as the input device. For example, a Universal Serial Bus (USB) port may be used to provide input and output devices.
[0122] In some embodiments, the power source QQ208 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electrical outlet), a photovoltaic device, or a battery, may also be used. The power source QQ208 may further include power circuitry for transferring power from the power source QQ208 itself and / or the external power source to various parts of the UEQQ200 via an interface, such as an input circuit or a power cable. The power transfer may be for charging the power source QQ208, for example. The power circuitry may perform some shaping, conversion, or other modification of the power from the power source QQ208 to make it suitable for each component of the UEQQ200 it powers.
[0123] Memory QQ210 may be or be configured to include random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disk, optical disk, hard disk, removable cartridge, flash drive, etc. In one example, memory QQ210 includes one or more application programs QQ214, such as an operating system, a web browser application, a widget, a gadget engine, or other applications, and corresponding data QQ216. Memory QQ210 may store any of a wide variety of operating systems or combinations of operating systems for use by UEQQ100.
[0124] The memory QQ210 may be configured to include multiple physical drive units such as a redundant array of independent disks (RAID), flash memory, a USB flash drive, an external hard disk drive, a thumb drive, a pen drive, a key drive, a high-density digital versatile disc (HD-DVD), an optical disk drive, an internal hard disk drive, a Blu-ray optical disk drive, a holographic digital data storage (HDDS) optical disk drive, an external mini-DIMM (Dual In-Line Memory Module), a synchronous dynamic random access memory (SDRAM), an external micro-DIMM (SDRAM), a smart card memory such as a tamper-resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs) such as a USIM and / or an ISIM, other memory, or any combination thereof. The UICC may be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly known as a "SIM card." Memory QQ210 may enable UEQQ200 to access instructions, application programs, and the like stored on temporary or non-transitory storage media to offload or upload data. An item of manufacture, such as one utilizing a communications system, may be tangibly embodied as or within memory QQ210, which may be or include a device-readable storage medium.
[0125] The processing circuit QQ202 may be configured to communicate with an access network or other networks using a communication interface QQ212. The communication interface QQ212 may include one or more communication subsystems and may include or be communicatively coupled to an antenna QQ222. The communication interface QQ212 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of other devices capable of wireless communication (e.g., other UEs or network nodes in the access network). Each transceiver may include a transmitter QQ218 and / or a receiver QQ220 appropriate for providing network communications (e.g., optical, electrical, frequency allocation, etc.). Moreover, the transmitter QQ218 and the receiver QQ220 may be coupled to one or more antennas (e.g., antenna QQ222), which may share circuit components, software, or firmware, or may alternatively be implemented separately.
[0126] In some embodiments, the communication capabilities of communication interface QQ212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near-field communication, location-based communication such as using the Global Positioning System (GPS) for determining location, other similar communication capabilities, or any combination thereof. Communication may be implemented according to one or more communication protocols and / or standards, such as, for example, IEEE 802.11, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, Transmission Control Protocol / Internet Protocol (TCP / IP), Synchronous Optical Networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), etc.
[0127] Regardless of the type of sensor, the UE may provide an output of data captured by its sensors to a network node via a wireless connection through its communication interface QQ212. Data captured by the UE's sensors may be communicated via other UEs to the network node via a wireless connection. The output may be periodic (e.g., once every 15 minutes when reporting sensed temperature), random (e.g., to balance the load of notifications from multiple sensors), in response to a triggering event (e.g., moisture is detected and an alert is sent), on request (e.g., a user-initiated request), or as a continuous stream (e.g., a live video feed of a patient).
[0128] As another example, the UE may include an actuator, motor, or switch associated with a communications interface configured to receive wireless input from a network node via a wireless connection. The state of the actuator, motor, or switch may change in response to the received wireless input. For example, the UE may include a motor that adjusts a control surface or rotor of a drone in flight in accordance with the received input, or a robotic arm that performs a medical procedure in accordance with the received input or control.
[0129] If the UE is in the form of an Internet of Things (IoT) device, it may be a device for use in one or more application domains, including but not limited to wearable technology in the city, extended industrial applications, and healthcare. Non-limiting examples of such IoT devices include, or are incorporated into, devices such as connected refrigerators or freezers, TVs, connected lighting fixtures, electricity meters, robot vacuums, voice-controlled smart speakers, home security cameras, motion detectors, thermostats, smoke detectors, door / window sensors, flood / moisture sensors, electric door locks, connected doorbells, air conditioning systems such as heat pumps, autonomous vehicles, surveillance systems, weather monitoring devices, vehicle parking monitoring devices, electric vehicle charging stations, smart watches, fitness trackers, head-mounted displays for augmented reality (AR) or virtual reality (VR), wearables for haptic augmentation or sensory enhancement, water sprinklers, animal or object tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and any type of medical device such as a heart rate monitor or remote-controlled surgical robot. A UE in the form of an IoT device comprises other components such as those described in connection with UE QQ200 shown in Figure QQ2, in addition to circuitry and / or software depending on the intended application of the IoT device.
[0130] As yet another specific example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements and transmits the results of such monitoring and / or measurements to other UEs and / or network nodes. The UE, in this case, may be an M2M device, which may also be referred to as an MTC device in the 3GPP context. As one example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a car, truck, ship, or aircraft, or other equipment that can monitor and / or report on its operational status or other functionality associated with its operation.
[0131] In practice, any number of UEs may be used together for a single use case. For example, a first UE may be a drone or integrated into a drone and provide drone speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When a user makes changes from the remote controller, the first UE may adjust the drone's throttle (e.g., by controlling an actuator) to increase or decrease the drone's speed. The first and / or second UE may also include more than one of the above-described functionalities. For example, a UE may include a sensor and an actuator and handle communication of data for both the speed sensor and the actuator.
[0132] Figure QQ3 illustrates a network node QQ300 according to some embodiments. As used herein, a network node refers to a device that is capable of, and is configured, arranged, and / or operable to communicate, directly or indirectly, with a UE and / or other network nodes or devices in a telecommunications network. Examples of a network node include, but are not limited to, access network nodes such as an access point (AP) (e.g., a wireless access point) and a base station (BS) (e.g., a radio base station, a Node B, an evolved Node B (eNB), and an NR Node B (gNB)). Other examples of a network node include, but are not limited to, a core network node such as a mobile switching center (MSC), a mobility management entity (MME), a home subscriber server (HSS), an access and mobility management function (AMF), a session management function (SMF), an authentication server function (AUSF), a subscriber identity suppression function (SIDF), a unified data management (UDM), a security edge protection proxy (SEPP), a network exposure function (NEF), and / or a node containing one or more functions of a user plane function (UPF).
[0133] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power levels), and thus may be referred to as femto, pico, micro, or macro base stations, depending on the amount of coverage provided. A base station may also be a relay node or a relay donor node that controls a relay. A network node may include one or more (or all) parts of a distributed radio base station, such as a centralized digital unit and / or a remote radio unit (RRU), sometimes referred to as a remote radio head (RRH). Such remote radio units may or may not be integrated with an antenna, such as an antenna-integrated radio. Some distributed radio base stations may also be referred to as nodes in a distributed antenna system (DAS).
[0134] Other examples of network nodes include multi-transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as a BS in an MSR, a network controller such as a radio network controller (RNC) or a base station controller (BSC), a base transceiver station (BTS), a transmission point, a transmitting node, a multi-cell / multicast coordinating entity (MCE), an operation and maintenance (O&M) node, an operation support system (OSS) node, a self-organizing network (SON) node, a positioning node (e.g., an evolved serving mobile location center (E-SMLC) and / or a minimization of drive test (MDT).
[0135] Network node QQ300 includes processing circuitry QQ302, memory QQ304, communication interface QQ306, and power supply QQ308, and / or any other components, or combinations thereof. Network node QQ300 may be composed of multiple physically separate components (e.g., a Node B component and an RNC component, or a BTS component and a BSC component, etc.), each of which may have its own respective components. In some scenarios where network node QQ300 comprises multiple separate components (e.g., a BTS and a BSC component), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple Node Bs. In such scenarios, each unique pair of Node B and RNC may, in some examples, be considered a single separate network node. In some embodiments, network node QQ300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be redundant (e.g., separate memories QQ304 for different RATs) and some components may be reused (e.g., the same antenna QQ310 may be shared by different RATs). Network node QQ300 may also include multiple sets of various illustrated components for different wireless technologies integrated into network node QQ300, such as GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, RFID (Radio Frequency Identification), or Bluetooth wireless technologies. The wireless technologies may be integrated into the same or different chips or chipsets and other components within network node QQ300.
[0136] The processing circuitry QQ302 may include one or more combinations of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or other suitable computing device, resources, or combinations of hardware, software, and / or coded logic operable, alone or in conjunction with other network node QQ300 components, such as memory QQ304, to provide the functionality of network node QQ300. For example, the processing circuitry QQ302 may be configured to cause the network node to perform a method such as that described with reference to FIG.
[0137] In some embodiments, the processing circuit QQ302 comprises a system-on-chip (SOC). In some embodiments, the processing circuit QQ302 includes one or more of a radio frequency (RF) transceiver circuit QQ312 and a baseband processing circuit QQ314. In some embodiments, the radio frequency (RF) transceiver circuit QQ312 and the baseband processing circuit QQ314 may be on separate chips (or chipsets), boards, or units, such as a radio unit and a digital unit. In alternative embodiments, some or all of the RF transceiver circuit QQ312 and the baseband processing circuit QQ314 may be on the same chip or chipset, board, or unit.
[0138] Memory QQ304 may include any type of volatile or non-volatile computer-readable memory, including, but not limited to, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disks), removable storage media (e.g., flash drives, compact discs (CDs), or digital video discs (DVDs)), and / or any other volatile or non-volatile non-transitory device-readable and / or computer-executable memory device that stores information, data, and / or instructions that can be used by processing circuit QQ302. Memory QQ304 may store any suitable instructions, data, or information, including applications, including one or more of computer programs, software, logic, rules, code, tables, and / or other instructions, executable by processing circuit QQ302 and usable by network node QQ300. The memory QQ304 may be used to store any computational results produced by the processing circuit QQ302 and / or any data received via the interface QQ306. In some embodiments, the processing circuit QQ302 and the memory QQ304 are integrated.
[0139] The communication interface QQ306 is used for wired or wireless communication of signaling and / or data between network nodes, access networks, core networks, and / or UEs. As shown, the communication interface QQ306 includes, for example, a port / terminal QQ316 for transmitting and receiving data to and from a network over a wired connection.
[0140] In embodiments in which network node QQ300 is an access network node, communication interface QQ306 also includes radio front-end circuitry QQ318, which is coupled to antenna QQ310 or, in some embodiments, may be part of antenna QQ310. In embodiments in which network node QQ300 is a core network node, the core network node may not include radio front-end circuitry QQ318 and antenna QQ310. Radio front-end circuitry QQ318 includes filter QQ320 and amplifier QQ322. Radio front-end circuitry QQ318 may be connected to antenna QQ310 and processing circuitry QQ302. The radio front-end circuitry may be configured to condition signals communicated between antenna QQ310 and processing circuitry QQ302. Radio front-end circuitry QQ318 may accept digital data to be sent to other network nodes or UEs via a wireless connection. The radio front-end circuit QQ318 may convert the digital data into a radio signal with appropriate channel and bandwidth parameters using a combination of a filter QQ320 and / or an amplifier QQ322. The radio signal may then be transmitted via the antenna QQ310. Similarly, when data is received, the antenna QQ310 collects the radio signal, which may then be converted into digital data by the radio front-end circuit QQ318. The digital data may be passed to the processing circuit QQ302. In other embodiments, the communication interface may include different components and / or different combinations of components.
[0141] In an alternative embodiment, the access network node QQ300 may not include a separate radio front-end circuit QQ318; rather, the processing circuit QQ302 may include the radio front-end circuit and may be connected to the antenna QQ310. Similarly, in some embodiments, all or some of the RF transceiver circuit QQ312 is part of the communication interface QQ306. In yet another embodiment, the communication interface QQ306 includes one or more ports or terminals QQ316, the radio front-end circuit QQ318, and the RF transceiver circuit QQ312 as part of a radio unit (not shown), and the communication interface QQ306 communicates with baseband processing circuit QQ314, which is part of a digital unit (not shown).
[0142] Antenna QQ310 may include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals. Antenna QQ310 may be coupled to radio front-end circuit QQ318 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, antenna QQ310 is separate from network node QQ300 and connectable to network node QQ300 through an interface or port.
[0143] The antenna QQ310, the communication interface QQ306, and / or the processing circuit QQ302 may be configured to perform any receiving operation and / or any acquiring operation described herein as being performed by a network node. Any information, data, and / or signals may be received from a UE, another network node, and / or any other network equipment. Similarly, the antenna QQ310, the communication interface QQ306, and / or the processing circuit QQ302 may be configured to perform any transmitting operation described herein as being performed by a network node. Any information, data, and / or signals may be transmitted to a UE, another network node, and / or any other network equipment.
[0144] The power supply QQ308 provides power to the various components of the network node QQ300 in a manner appropriate for each component (e.g., at the voltage and current levels required for each component). The power supply QQ308 may include or be coupled to power management circuitry for providing power to the components of the network node QQ300 to perform the functionality described herein. For example, the network node QQ300 may be connectable to an external power source (e.g., a power grid, an electrical outlet) via an input circuit or interface, such as an electrical cable, whereby the external power source provides power to the power circuitry of the power supply QQ308. As a further example, the power supply QQ308 may include a source of power in the form of a battery or battery pack connected to or integrated into the power circuitry. The battery may provide backup power in case of failure of the external power source.
[0145] Embodiments of network node QQ300 may include additional components other than those shown in Figure QQ3 to provide certain aspects of the network node's functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, network node QQ300 may include user interface devices that allow information to be input to and output from network node QQ300. This may enable a user to perform diagnostic, maintenance, repair, and other management functions on network node QQ300.
[0146] FIG. QQ4 is a block diagram of a host QQ400, which may be an embodiment of host QQ116 of FIG. QQ1, in accordance with various aspects described herein. As used herein, host QQ400 may be or include hardware and / or software in various combinations, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, a container, or processing resources within a server farm. Host QQ400 may provide one or more services to one or more UEs.
[0147] Host QQ400 includes a processing circuit QQ402, a network interface QQ408, a power supply QQ410, and memory QQ412 operably coupled via bus QQ404 to an input / output interface QQ406. In other embodiments, other components may be included, the functionality of which may be substantially similar to those described with respect to the devices in previous figures, such as Figures QQ2 and QQ3, and therefore those descriptions are generally applicable to the corresponding components of host QQ400.
[0148] Memory QQ412 may include one or more computer programs, including one or more host application programs QQ414, and data QQ416, which may include user data, such as data generated by a UE for host QQ400 or data generated by host QQ400 for a UE. An embodiment of host QQ400 may utilize only a subset or all of the illustrated components. Host application program QQ414 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for different UE classes, types, or implementations (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application program QQ 414 may also provide user authentication and license checks, and may periodically report health, route, and content availability to a central node, such as a device in or at the edge of the core network. Thus, the host QQ 400 may select and / or point to different hosts for over-the-top services for the UE. The host application program QQ 414 may support a variety of protocols, such as the HTTP Live Streaming (HLS) protocol, the Real-Time Messaging Protocol (RTMP), the Real-Time Streaming Protocol (RTSP), and Dynamic Adaptive Streaming over HTTP (MPEG-DASH).
[0149] Figure QQ5 is a block diagram illustrating a virtualization environment QQ500 in which functionality implemented in some embodiments may be virtualized. In this context, virtualization means for creating a virtual version of an apparatus or device may include a virtualized hardware platform, storage devices, and networking resources. As used herein, virtualization may apply to any device or component described herein and refer to implementations in which at least a portion of its functionality is implemented as one or more virtual components. Some or all of the functionality described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented within one or more virtual environments QQ500 hosted by one or more hardware nodes, such as an access network node, a wireless device / UE, a core network node, or a hardware computing device acting as a host. Furthermore, in embodiments in which a virtualized node does not require wireless connectivity (e.g., a core network node or host), the node may be virtualized in its entirety.
[0150] Application QQ502 (which may alternatively be referred to as a software instance, a virtual appliance, a network function, a virtual node, a virtual network function, etc.) runs in virtualized environment QQ500 to implement some of the features, functionality and / or benefits of some of the embodiments disclosed herein.
[0151] The hardware QQ504 may include processing circuitry, memory storing software and / or instructions executable by the hardware processing circuitry, and / or hardware devices as described herein, such as network interfaces and input / output interfaces. Software may be executed by the processing circuitry to instantiate one or more virtualization layers QQ506 (also referred to as a hypervisor or virtual machine monitor (VMM)), provide VMQQ508a and VMQQ508b (one or more of which may be collectively referred to as VMQQ508), and / or perform any of the functions, features, and / or benefits described in connection with some embodiments described herein. The virtualization layer QQ506 may present a virtual operating platform that appears as networking hardware to the virtual machine QQ508.
[0152] VMQQ 508 may include virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and may be executed by a corresponding virtualization layer QQ 506. Various embodiments of an instance of virtual appliance QQ 502 may be implemented in one or more of VMQQ 508, and the implementation may be done in various ways. Hardware virtualization is referred to in some contexts as network functions virtualization (NFV). NFV may be used to aggregate many network equipment types into industry-standard, high-capacity server hardware, physical switches, and physical storage that may be located in data centers and customer premises equipment.
[0153] In the context of NFV, a VMQQ 508 may be a software implementation of a physical machine that runs programs as if they were running on a physical, non-virtualized machine. Each VMQQ 508 and the portion of the hardware QQ 504 that runs that VM, whether on hardware dedicated to that VM and / or shared by that VM with other VMs, forms a separate virtual network element. Also in the context of NFV, a virtual network function is responsible for handling specific network functions running in one or more VMQQs 508 on top of a hardware QQ 504 and corresponds to an application QQ 502.
[0154] The hardware QQ504 may be implemented in a standalone network node with generic or proprietary components. The hardware QQ504 may implement some functions via virtualization. Alternatively, the hardware QQ504 may be part of a larger hardware cluster (e.g., in a data center or CPE) where multiple hardware nodes cooperate and are managed via a management and orchestration QQ510, which oversees, among other things, the lifecycle management of the application QQ502. In some embodiments, the hardware QQ504 is coupled to one or more radio units, each including one or more transmitters and one or more receivers, which may be coupled to one or more antennas. The radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces or may be used in combination with virtual components, such as radio access nodes or base stations, to provide wireless capabilities to virtual nodes. In some embodiments, some signaling may be provided using the control system QQ512, which may alternatively be used for communication between the hardware nodes and the radio units.
[0155] Figure QQ6 shows a communication diagram of a host computer QQ602 communicating with a UE QQ606 via a network node QQ604 over a partially wireless connection according to some embodiments. Exemplary implementations according to various embodiments of the UEs (UE QQ112a in Figure QQ1 and / or UE QQ200 in Figure QQ2), network nodes (network node QQ110a in Figure QQ1 and / or network node QQ300 in Figure QQ3), and hosts (host QQ116 in Figure QQ1 and / or host QQ400 in Figure QQ4) discussed in the preceding paragraphs will now be described with reference to Figure QQ6.
[0156] Similar to host QQ 400, an embodiment of host QQ 602 includes hardware such as a communications interface, processing circuitry, and memory. Host QQ 602 also includes software stored within or accessible by host QQ 602 and executable by the processing circuitry. The software includes a host application that may be operable to provide services to a remote user, such as UEQQ 606, connecting via an over-the-top (OTT) connection QQ 650 extending between UEQQ 606 and host computer QQ 602. During the provision of services to the remote user, the host application may provide user data that is transmitted using the OTT connection QQ 650.
[0157] Network node QQ604 includes hardware that enables communication with hosts QQ602 and UEQQ606. Connection QQ660 may be direct or may pass through one or more other intermediate networks, such as a core network (such as core network QQ106 in Figure QQ1) and / or one or more public, private, or hosted networks. For example, the intermediate network may be a backbone network or the Internet.
[0158] The UEQQ 606 also includes software stored within or accessible by the UEQQ 606 and executable by the processing circuitry of the UE. This software includes a client application, such as a web browser or operator-specific "app," that may be operable to provide services to a human or non-human user via the UEQQ 606, with the support of the host QQ 602. Host applications running on the host QQ 602 may communicate with client applications running on the host QQ 606 via an OTT connection QQ 650 that terminates at the UEQQ 606 and the host QQ 602. During the provision of services to the user, the client application on the UE may receive request data from the host application on the host and provide user data in response to the request data. The OTT connection QQ 650 may transport both request data and user data. The client application on the UE may interact with the user to generate user data that it provides to the host application through the OTT connection QQ 650.
[0159] OTT connection QQ650 may extend via connection QQ660 between host QQ602 and network node QQ604 and via wireless connection QQ670 between network node QQ604 and UEQQ606, providing connectivity between host QQ602 and UEQQ606. Connection QQ660 and wireless connection QQ670 over which OTT connection QQ650 may be provided are depicted abstractly to illustrate communication between host QQ602 and UEQQ606 via network node QQ604 without explicit reference to any intermediate devices and the precise routing of messages through those devices.
[0160] As an example of transmitting data over the OTT connection QQ650, in step QQ608, the host QQ602 provides user data, which may be done by executing a host application. In some embodiments, the user data is associated with a specific human user interacting with the UEQQ606. In other embodiments, the user data is associated with the UEQQ606 sharing data with the host QQ602 without explicit human interaction. In step QQ610, the host QQ602 initiates a transmission to the UEQQ606 carrying user data. The host QQ602 may initiate the transmission in response to a request sent by the UEQQ606. The request may be triggered by human interaction with the UEQQ606 or by the operation of a client application running on the UEQQ606. The transmission may pass through the network node QQ604 in accordance with the teachings of embodiments described throughout this disclosure. In response, in step QQ612, network node QQ604 transmits the user data carried in the transmission initiated by host QQ602 to UEQQ606, in accordance with the teachings of embodiments described throughout this disclosure. In step QQ614, UEQQ606 receives the user data carried in the transmission, which may be done by a client application running on UEQQ606 that is associated with a host application executed by host QQ602.
[0161] In some examples, UEQQ606 executes a client application, which provides user data destined for host QQ602. The user data may be provided in reaction or response to receiving the data from host QQ602. In response, UEQQ606 may provide the user data in step QQ616, which may be done by executing the client application. While providing the user data, the client application may further consider user input received from the user via an input / output interface of UEQQ606. Regardless of the specific manner in which the user data is provided, UEQQ606 initiates transmission of the user data to host QQ602 via network node QQ604 in step QQ618. In step QQ620, network node QQ604 receives the user data from UEQQ606 and initiates transmission of the received user data to host QQ602, in accordance with the teachings of embodiments described throughout this disclosure. In step QQ622, host QQ602 receives the user data carried in the transmission initiated by UEQQ606.
[0162] In an exemplary scenario, factory status information may be collected and analyzed by the host QQ 602. As another example, the host QQ 602 may process audio and video data, possibly obtained from UEs, for use in generating maps. As another example, the host QQ 602 may collect and analyze real-time data to assist in vehicular congestion control (e.g., traffic light control). As another example, the host QQ 602 may store surveillance video uploaded by UEs. As another example, the host QQ 602 may store or control access to media content, such as video, audio, VR, or AR, that may be broadcast, multicast, or unicast to UEs. As another example, the host QQ 602 may be used for energy pricing, remote control of non-time-critical power loads for balancing power generation needs, location services, presentation services (e.g., compiling diagrams from data collected from remote devices), or any other function that collects, acquires, stores, analyzes, and / or transmits data.
[0163] In some examples, measurement procedures may be provided to monitor data rates, latency, and other factors that may be improved by one or more embodiments. There may also be optional network functionality for reconfiguring the OTT connection QQ650 between host QQ602 and UEQQ606 in response to fluctuations in the measurements. The measurement procedures and / or network functionality for reconfiguring the OTT connection may be implemented in software and hardware in host QQ602 and / or UEQQ606. In some embodiments, sensors (not shown) may be deployed in or associated with other devices through which the OTT connection QQ650 passes, and these sensors may participate in the measurement procedures by providing values for the monitored quantities exemplified above or other physical quantities from which the monitored quantities may be calculated or estimated by software. Reconfiguration of the OTT connection QQ650 may include message formats, retransmission settings, preferred routing, etc., and the reconfiguration need not directly alter the operation of network node QQ604. Such procedures and functionality may be known or practiced in the art. In one embodiment, the measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation time, latency, etc. by the host QQ 602. The measurements may be implemented by software using the OTT connection QQ 650 to send messages, specifically empty or "dummy" messages, while monitoring propagation time, errors, etc.
[0164] While the computing devices (e.g., UEs, network nodes, hosts) described herein may include combinations of the illustrated hardware components, other embodiments may include computing devices with different combinations of components. It should be understood that the computing devices may include any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. The determining, calculating, obtaining, or similar operations described herein may be performed by processing circuitry, which may process information by, for example, transforming the obtained information into other information, comparing the obtained or transformed information with information stored at a network node, and / or performing one or more operations based on the obtained or transformed information, and making a decision as a result of the processing. Moreover, while components are depicted as single boxes located within larger boxes or nested within multiple boxes, in reality, the computing device may include multiple different physical components that make up the illustrated single component, and functionality may be partitioned among the separate components. For example, a communication interface may be configured to include any of the components described herein, and the functionality of those components may be partitioned between the processing circuitry and the communication interface. In other examples, the computationally less intensive functions of any of these components may be implemented in software or firmware, and the computationally intensive functions may be implemented in hardware.
[0165] In some embodiments, some or all of the functionality described herein may be provided by a processing circuit executing instructions stored in a memory, which in some embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by a processing circuit, such as in a hardwired manner, without executing instructions stored on a separate or discrete device-readable storage medium. In any of these specific embodiments, the processing circuit can be configured to perform the described functionality regardless of whether it executes instructions stored on a non-transitory computer-readable storage medium. Benefits provided by such functionality are not limited to just the processing circuit or other components of the computing device, but are enjoyed by the computing device as a whole and / or by end users and wireless networks in general.
[0166] The foregoing merely illustrates the principles of the present disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in light of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of the present disclosure and therefore may be within the scope of the present disclosure. The various exemplary embodiments can be used in conjunction with, as well as interchangeably with, one another, as will be understood by those skilled in the art.
[0167] For the avoidance of doubt, the following numbered statements refer to embodiments of the present disclosure:
[0168] Group A Embodiment (UE) 1. A method in a user equipment (UE), comprising: receiving a first Minimized Drive Test (MDT) configuration associated with measurements of a first Data Radio Bearer (DRB) type; receiving a second MDT configuration associated with measurements of the first DRB type; selecting one of the first MDT configuration and the second MDT configuration; reporting according to the selected MDT configuration; and A method comprising: 2. The method of embodiment 1, wherein the first MDT configuration is received from a first network node and the second MDT configuration is received from a second network node. 3. The method of embodiment 2, wherein the UE operates in dual connectivity with the first network node and the second network node. 4. The method of embodiment 2 or 3, wherein the first network node is a master node (MN) and the second network node is a secondary node (SN). 5. The method of embodiment 1, wherein the first and second MDT configurations are received from the same network node. 6. The method of any one of embodiments 1 to 5, wherein selecting one MDT configuration includes selecting a most recently received MDT configuration. 7. Selecting one MDT configuration is determining that the UE is already configured according to the first MDT configuration for the first DRB type; selecting the first MDT configuration; 5. The method according to any one of claims 1 to 4, comprising: 8. The method of embodiment 7, further comprising: sending an indication to a network node indicating that the UE is configured according to the first MDT configuration for the first DRB type. 9. Reporting in accordance with said selected MDT configuration: performing the first DRB type measurement according to the selected MDT configuration; reporting the results of the measurements performed; and 9. The method of any one of embodiments 1 to 8, comprising: 10. A method according to any one of embodiments 1 to 9, wherein the measurements from the first and / or second MDT configurations quantify packet delay in a radio access network. 11. A method according to any one of embodiments 1 to 10, wherein the measurements according to the first and / or second MDT configurations include an uplink (UL) Packet Data Convergence Protocol (PDCP) packet average delay measurement. 12. A method according to any one of embodiments 1 to 10, wherein the measurements from the first and / or second MDT configurations include D1 measurements. 13. The method according to any one of embodiments 1 to 12, wherein the first DRB type includes one of a master cell group (MCG) bearer, a secondary cell group (SCG) bearer, and a split bearer. 14. Receiving a third MDT configuration for measurements of a second DRB type; reporting according to said third MDT configuration; 14. The method of any one of embodiments 1 to 13, further comprising: 15. Reporting under the third MDT structure: performing the second DRB-type measurements according to the third MDT configuration; and reporting the results of the measurements performed; and 15. The method of embodiment 14, comprising:
[0169] Group B (Network nodes such as MN and SN) 1. A method in a first network node, wherein a user equipment (UE) is operating in dual connectivity with the first network node and at least a second network node, the method comprising: determining whether to configure the UE to report measurements of a first data radio bearer (DRB) according to a first Minimized Drive Test (MDT) configuration based on a DRB type of the first DRB; A method comprising: 2. determining based on the DRB type determining whether the UE is already configured to report MDT measurements for a DRB of the same DRB type as the first DRB. 2. The method of embodiment 1. 3. The said determination is and determining, in response to determining that the UE has an existing configuration for reporting measurements for a DRB of the same DRB type as the first DRB, not to configure the UE to report measurements for the first DRB according to the first MDT configuration. 3. The method of embodiment 1 or 2. 4. In response to determining that the UE has an existing configuration reporting measurements for DRBs of the same DRB type as the first DRB, releasing the UE from the existing configuration; configuring the UE to report measurements for the first DRB according to the first MDT configuration; 3. The method of embodiment 1 or 2, further comprising: 5. In response to determining that the UE does not have an existing configuration for reporting measurements of a DRB of the same DRB type as the first DRB, configuring the UE to report measurements of the first DRB according to the first MDT configuration. The method according to any one of embodiments 1 to 4. 6. The method further includes receiving the first MDT configuration before determining whether to configure the UE to report DRB measurements according to the first MDT configuration. The method according to any one of embodiments 1 to 5. 7. The first MDT configuration is received from an Operation, Administration and Maintenance (OAM) or core network node. 7. The method of embodiment 6. 8. The first MDT configuration includes M6 measurements. The method according to any one of embodiments 1 to 7. 9. Measurements from the first MDT configuration quantify packet delay in the radio access network. The method according to any one of embodiments 1 to 8. 10. The measurements according to the first MDT configuration include an uplink (UL) Packet Data Convergence Protocol (PDCP) packet average delay measurement. The method according to any one of embodiments 1 to 9. 11. The measurements according to the first MDT configuration include D1 measurements. The method according to any one of embodiments 1 to 10. 12. The DRB type includes one of a master cell group (MCG) bearer, a secondary cell group (SCG) bearer, and a split bearer. The method according to any one of embodiments 1 to 11. 13. The first network node is a master node (MN) or a secondary node (SN). The method according to any one of embodiments 1 to 12. 14. The second network node is a secondary node (SN) or a master node (MN). The method according to any one of embodiments 1 to 13.
[0170] Group C Embodiments 1. A user device, comprising: a processing circuit configured to cause a user device to perform the steps of any of the embodiments of Group A; a power supply circuit configured to provide power to the processing circuit; A user device comprising: 2. A network node, comprising: processing circuitry configured to cause a network node to perform the steps of any of the Group B embodiments; a power supply circuit configured to provide power to the processing circuit; A network node comprising: 3. A user equipment (UE), an antenna configured to transmit and receive wireless signals; a radio front-end circuit coupled to the antenna and the processing circuit and configured to condition signals communicated between the antenna and the processing circuit; a processing circuit configured to perform the steps of any of the embodiments of Group A; an input interface connected to the processing circuit and configured to allow input of information into the UE to be processed by the processing circuit; an output interface coupled to the processing circuit and configured to output information from the UE that has been processed by the processing circuit; a battery connected to the processing circuit and configured to power the UE; UE is equipped with. 4. A host configured to operate in a communication system to provide an over-the-top (OTT) service, comprising: processing circuitry configured to provide user data; a network interface configured to initiate transmission of user data to a cellular network for transmission to a user equipment (UE); Equipped with The UE comprises a communication interface and a processing circuit, and the communication interface and the processing circuit of the UE are configured to perform the steps of any of the embodiments of Group A to receive user data from the host. host. 5. The host of any preceding embodiment, wherein the cellular network further includes a network node configured to communicate with the UE to transmit user data from the host to the UE. 6. The processing circuitry of the host is configured to execute a host application, thereby providing user data; The host application is configured to interact with a client application running on the UE, the client application being associated with the host application. 2. The host of any one of the preceding two embodiments. 7. A method implemented by a host operating in a communication system further including a network node and a user equipment (UE), comprising: providing user data to the UE; initiating a transmission to transfer user data to the UE via a cellular network including a network node, the UE performing the operations of any of the embodiments in Group A to receive the user data from the host; A method comprising: 8. Further including: executing, at the host, a host application associated with the client application running on the UE to receive user data from the UE. 10. The method of claim 1, wherein the 9. At the host, further comprising: sending input data to a client application running on the UE; User data is provided by the client application in response to input data from the host application. 10. The method of claim 1, wherein the 10. A host configured to operate in a communication system to provide an over-the-top (OTT) service, comprising: processing circuitry configured to provide user data; a network interface configured to initiate transmission of user data to a cellular network for transmission to a user equipment (UE); Equipped with The UE comprises a communication interface and a processing circuit, and the communication interface and the processing circuit of the UE are configured to perform the steps of any of the embodiments of Group A to transmit user data to the host. host. 11. The cellular network further includes a network node configured to communicate with the UE to transmit user data from the UE to the host. 10. The host of any preceding embodiment. 12. The processing circuitry of the host is configured to execute a host application, thereby providing user data; The host application is configured to interact with a client application running on the UE, the client application being associated with the host application. 2. The host of any one of the preceding two embodiments. 13. A method implemented by a host configured to operate in a communication system further including a network node and a user equipment (UE), comprising: receiving, at the host, user data transmitted by the UE via the network node to the host, wherein the UE performs the steps of any of the embodiments of Group A to transmit the user data to the host; method. 14. Further including, at the host, executing a host application associated with the client application running on the UE to receive user data from the UE. 10. The method of claim 1, wherein the 15. Further comprising: at the host, sending input data to a client application running on the UE; User data is provided by the client application in response to input data from the host application. 10. The method of claim 1, wherein the 16. A host configured to operate in a communication system to provide over-the-top (OTT) services, comprising: processing circuitry configured to provide user data; a host comprising: a network interface configured to initiate transmission of user data to a network node in a cellular network for transmission to a user equipment (UE), the network node having a communications interface and processing circuitry, the processing circuitry of the network node configured to perform the operations of any of the embodiments in Group B to transmit the user data from the host to the UE; and 17. The processing circuitry of the host is configured to execute a host application that provides user data; The UE comprises processing circuitry configured to execute a client application associated with the host application and to receive transmissions of user data from the host. 10. The host of any preceding embodiment. 18. A method implemented in a host configured to operate in a communication system further including a network node and a user equipment (UE), comprising: providing user data to the UE; initiating a transmission to transfer user data to the UE over a cellular network including a network node, the network node performing the operations of any of the embodiments of Group B to transfer the user data from the host to the UE; A method comprising: 19. At the network node, further comprising transmitting user data provided by the host for the UE. 10. The method of claim 1, wherein the 20. User data is provided at the host by executing a host application that interacts with a client application running on the UE, the client application being associated with the host application. 10. The method of any of the preceding two embodiments. 21. A communication system configured to provide over-the-top services, comprising: a processing circuit configured to provide user data to a user equipment (UE), the user data relating to an over-the-top service; and a network interface configured to initiate transmission of user data towards a cellular network node for transmission to a UE, the network node having a communications interface and processing circuitry, the processing circuitry of the network node configured to perform the operations of any of the embodiments in Group B to transmit the user data from a host to the UE; a host including: Communication system. 22. Further comprising a network node and / or user equipment 10. The communication system of any preceding embodiment. 23. A host configured to operate in a communication system to provide over-the-top (OTT) services, comprising: a processing circuit configured to initiate reception of user data; a network interface configured to receive user data from a network node of a cellular network, the network node having a communications interface and processing circuitry, the processing circuitry of the network node configured to perform the operations of any of the Group B embodiments to receive user data from a user equipment (UE) for a host; and A host. 24. The processing circuitry of the host is configured to execute a host application, thereby providing user data; The host application is configured to interact with a client application running on the UE, the client application being associated with the host application. 10. The host of any preceding embodiment. 25. Initiating receipt of user data includes requesting the user data. 10. The host of any of the preceding two embodiments. 26. A method implemented by a host configured to operate in a communication system further including a network node and a user equipment (UE), comprising: and initiating, at the host, reception of user data from the UE, the user data originating from a transmission received by the network node from the UE, the network node performing the steps of any of the embodiments of Group B to receive the user data from the UE for the host. method. 27. At the network node, further comprising transmitting the received user data to the host. 10. The method of claim 1, wherein the
Claims
1. A method in a user equipment (UE) (QQ112), comprising: receiving (702) from a first network node (QQ110A) a first Minimized Drive Test (MDT) configuration associated with measurements on a first Data Radio Bearer (DRB) of a first DRB type, the first DRB type including one of a Master Cell Group (MCG) bearer type, a Secondary Cell Group (SCG) bearer type, and a Split Bearer type; receiving (704) a second MDT configuration from a second network node (QQ110B) related to measurements on a second DRB of the first DRB type; reporting (706) a plurality of measurement reports, wherein measurements according to the first MDT configuration are reported to the first network node and measurements according to the second MDT configuration are reported to the second network node; Including, The method, wherein the reporting (706) of a plurality of measurement reports is performed after the receiving (702) the first MDT configuration and the receiving (704) the second MDT configuration.
2. The reporting (706) of the plurality of measurement reports comprises: performing measurements of the first DRB according to the first MDT configuration; performing measurements of the second DRB according to the second MDT configuration; and reporting the results of the measurements performed; and Contains The method of claim 1.
3. The measurements according to one or more of the first MDT configuration and the second MDT configuration quantify packet delay in a radio access network. The method of claim 1.
4. The measurements according to one or more of the first MDT configuration and the second MDT configuration include an uplink (UL) Packet Data Convergence Protocol (PDCP) packet average delay measurement. The method of claim 1.
5. The measurements according to one or more of the first MDT configuration and the second MDT configuration include D1 measurements. The method of claim 4.
6. The UE is operating in dual connectivity with the first network node (QQ110A) and the second network node (QQ110B). The method of claim 1.
7. The first network node (QQ110A) is a master node (MN), and the second network node (QQ110B) is a secondary node (SN). The method of claim 1.
8. and transmitting an indication to a network node indicating that the UE is configured for the first DRB type according to both the first MDT configuration and the second MDT configuration (708). The method of claim 1.
9. receiving (710) a third MDT configuration related to measurements on a third DRB of a second DRB type; reporting (712) according to the third MDT configuration; Also includes The method of claim 1.
10. Reporting (712) according to the third MDT configuration includes: performing measurements of the third DRB according to the third MDT configuration; and reporting a result of the performed third DRB measurement; and Contains 10. The method of claim 9.
11. A user equipment (UE), receiving (702) from a first network node (QQ110A) a first Minimized Drive Test (MDT) configuration related to measurements of a first Data Radio Bearer (DRB) of a first DRB type, the first DRB type comprising one of a Master Cell Group (MCG) bearer type, a Secondary Cell Group (SCG) bearer type, and a Split Bearer type; receiving (704) a second MDT configuration from a second network node (QQ110B), the second MDT configuration relating to measurements on a second DRB of the first DRB type; Reporting (706) multiple measurement reports It is configured as follows: the UE is configured to report measurements according to the first MDT configuration to the first network node, and the UE is configured to report measurements according to the second MDT configuration to the second network node; The UE is configured to report the plurality of measurement reports after the UE receives the first MDT configuration and the second MDT configuration.
12. The UE is further configured to perform the method according to any one of claims 2 to 10. The UE of claim 11.
Citation Information
Patent Citations
MDT for secondary cell group and secondary cells
WO2021024049A1