APPARATUS AND METHODS FOR CELL IDENTIFICATION IN WIRELESS NETWORKS

Abstract

Apparatus and methods for physical cell identification within one or more wireless networks. In one embodiment, conflicts in PCI values which may exist within two or more mobile networks (e.g., PLMNs) of respective different operators when unlicensed spectrum is utilized (e.g., according to 3GPP 5G NR-U technology) are resolved. In one implementation, this functionality is provided by specifying one or more mobility-related parameters associated with various UE, such that serving gNBs can determine whether a given UE requires a mobility context, and as such whether it should conduct subsequent RF measurement reporting to report back potential conflicts in PCI it may encounter to the gNB. In one variant, the measurement reporting is configured to comply with 5G NR-U required “listen-before-talk” or LBT protocols; i.e., to measure parameters consistent with the LBT protocols to detect any such PCI-based conflicts.

Claims

1-15. (canceled)

16. A computerized method for cell identification within a wireless network, the computerized method comprising: identifying one or more candidate computerized client devices for PCI (physical cell identification) ambiguity resolution; instructing the one or more candidate computerized client devices to perform a measurement protocol; and based on data relating to the measurement protocol, applying computerized logic to determine whether to update at least one of a then-current data structure to perform at least one of an inclusion or exclusion of at least one PCI value.

17. The computerized method of claim 16, wherein the identifying of the one or more candidate computerized client devices for the PCI ambiguity resolution comprises identifying the one or more candidate computerized client devices based at least on a mobility-related factor.

18. The computerized method of claim 17, where the identifying the one or more candidate computerized client devices for the PCI confusion resolution based at least on the mobility-related factor comprises identifying at least one of the one or more candidate computerized client devices as requiring application of an ambiguity resolution mechanism based at least on a presence of a prescribed parameter relating to at least one of (i) intra-cell mobility or (ii) inter-cell mobility.

19. The computerized method of claim 18, wherein the presence of the prescribed parameter comprises causing an access and mobility management function (AMF) apparatus to initiate an initial context setup procedure with respect to the at least one of the one or more candidate computerized client devices.

20. The computerized method of claim 19, wherein the causing the AMF apparatus to initiate an initial context setup procedure is based on at least one of: (i) existence of a logical Next Generation (NG)-connection for the at least one of the one or more candidate computerized client devices, or (ii) receipt by the AMF apparatus of a radio access network (RAN) user equipment (UE) Next Generation Access Point (NGAP) identification (ID) information element (IE).

21. The computerized method of claim 17, wherein the identifying the one or more candidate computerized client devices for the PCI ambiguity resolution comprises causing a mobility management apparatus to: (i) access subscription data to obtain mobility-related data associated with the one or more candidate computerized client devices; and (ii) insert at least a portion of the mobility-related data into one or more respective context messages.

22. The computerized method of claim 21, further comprising: receiving the one or more respective context messages from the mobility management apparatus; and analyzing the one or more respective context messages to determine one or more respective mobility statuses of the one or more candidate computerized client devices; and utilizing the determined one or more respective mobility statuses to identify at least one of the one or more candidate computerized client devices as requiring application of the ambiguity resolution mechanism.

23. The computerized method of claim 16, wherein the instructing of the one or more candidate computerized client devices to perform the measurement protocol comprises instructing the one or more candidate computerized client devices to perform the measurement protocol using at least an LBT (Listen Before Talk) protocol.

24. The computerized method of claim 16, wherein the instructing of the one or more candidate computerized client devices to perform the measurement protocol comprises: determining one or more target PCI values; determining one or more duration values, the one or more duration values each specifying a duration for which the measurement protocol is to be performed; instructing the one or more candidate computerized client devices with the one or more target PCI values and one or more duration values; receiving the data relating to the measurement protocol from the one or more candidate computerized client devices; and based at least on the data relating to the measurement protocol, extracting reporting data for the one or more target PCI values.

25. The computerized method of claim 24, wherein the extracting of the reporting data for the one or more target PCI values comprises extracting signal strength data for one or more prescribed frequencies.

26. The computerized method of claim 23, wherein instructing the one or more candidate computerized client devices with the one or more target PCI values and one or more duration values, respectively, comprises instructing at least one of the one or more candidate computerized client devices with a scan time, the scan time comprising a time which the at least one of the one or more candidate computerized client devices is to scan for all possible SSBs (synchronization signal blocks) being broadcasted in a same PCI by different PLMNs (public land mobile networks).

27. The computerized method of claim 16, wherein the applying of the computerized logic to determine whether to update the at least one of a then-current data structure to perform the at least one of the inclusion or the exclusion comprises: extracting reporting data from the data relating to the measurement protocol for each target PCI value; and evaluating the extracted reporting data for each target PCI value to determine whether at least one conflict is present.

28. The computerized method of claim 27, further comprising, based on a determination that the at least one conflict is present, updating the at least one then-current data structure to perform the at least one of the inclusion or the exclusion , the updating configured to enable or disable one or more measurement reports from one or more respective PCIs of a PLMN (public land mobile network).

29. Computerized wireless network apparatus, comprising: a digital processor apparatus; wireless network interface apparatus configured for data communication with the digital processor apparatus, at least one wireless-enabled data network, and a plurality of computerized wireless client devices; and at least one storage device in data communication with the digital processor apparatus, the at least one storage device comprising at least one computer program having a plurality of instructions configured to, when executed by the digital processor apparatus, cause the computerized wireless network apparatus to: identify at least one of the plurality of computerized wireless client devices for which a prescribed operational configuration is applicable; apply a cell identifier resolution mechanism to only one or more others of the plurality of computerized wireless client devices and not the at least one computerized wireless client device; cause instruction of the one or more others of the plurality of computerized wireless client devices to perform a measurement protocol pursuant to the cell identifier resolution mechanism; and based on one or more results of the performance of the measurement protocol, cause configuration of at least one data structure relating to cell identifiers.

30. The computerized wireless network apparatus of claim 29, wherein the plurality of instructions are further configured to, when executed by the digital processor apparatus, cause the computerized wireless network apparatus to: obtain one or more Public Land Mobile Network identification (PLMN ID) values via a PLMN-ID value within a measurement results reporting information element (IE).

31. The computerized base station apparatus of claim 29, wherein the prescribed operational configuration comprises a Fixed Wireless Access (FWA) configuration in which the at least one of the plurality of computerized wireless client devices is configured to not utilize either intra-cell mobility or inter-cell mobility.

32. The computerized wireless network apparatus of claim 29, wherein: the computerized wireless network apparatus comprises at least one of a 3rd Generation Partnership Project (3GPP)-compliant gNB (gNodeB) or a 3GPP-compliant AMF (access management function) apparatus; the plurality of computerized wireless client devices comprise a plurality of 3GPP-compliant user equipment (UEs); and the cell identifiers comprise PCI (Physical Cell identification) values.

33. The computerized wireless network apparatus of claim 29, wherein the identification of the at least one of the plurality of computerized wireless client devices for which the prescribed operational configuration is applicable comprises evaluation of at least one mobility-related parameter associated with at least a portion of the plurality of wireless computerized client devices.

34. The computerized base station apparatus of claim 29, wherein the causation of the instruction of the others of the plurality of computerized wireless client devices to perform the measurement protocol pursuant to the cell identifier resolution mechanism comprises causation of an instruction to only ones of the plurality of computerized wireless client devices not being used for a fixed wireless application to perform the measurement protocol only for certain selected one or more PCI (physical cell identification) values.

35. A method of cell identifier conflict resolution relating to unlicensed spectrum utilization within a wireless system having a plurality of wireless-enabled client devices associated therewith, the method comprising: specifying one or more mobility-related parameters associated with at least one of the wireless-enabled client devices; utilizing, via one or more apparatus of the wireless system, the one or more mobility-related parameters to determine whether the at least one wireless-enabled client device requires a mobility context; and determining, based at least on the determination of whether the at least one wireless-enabled client device requires a mobility context, that the at least one wireless-enabled client device should perform at least one RF (radio frequency) measurement protocol to enable reporting of data relating to performance of the at least one RF measurement protocol back to the one or more apparatus of the wireless system.

36. The method of claim 35, further comprising: causing the at least one wireless-enabled client device to perform the at least one RF measurement protocol and the reporting of the data; and identifying, based at least on the reported data, at least one conflict in PCI encountered during operation by the at least one wireless-enabled client device.

37. The method of claim 36, wherein: the at least one wireless-enabled client device comprises a 5G NR-U (Fifth Generation New Radio-Unlicensed) compliant UE (user equipment) operating within an NR-U unlicensed frequency band; and the performance of the at least one RF measurement protocol and the reporting of the data comply with 5G NR-U listen-before-talk (LBT) and data reporting protocols, respectively.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0035] FIG. 1 is a functional block diagram of a prior art 5G system architecture and the various components thereof.

[0036] FIG. 2a is a block diagram showing the extant architecture for interworking between 5GS and EPC/E-UTRAN as defined in 3GPP TS 23.501 (FIG. 4.3.1-1 thereof), specifically the non-roaming architecture for interworking between the 5GS and the EPC/E-UTRAN.

[0037] FIG. 2b shows a prior art roaming architecture counterpart to the architecture of FIG. 2a (i.e., with HPLMN and visited network (VPLMN)).

[0038] FIG. 2c shows a graphical representation of the PCI “confusion” problem between licensed and unlicensed spectrum networks within the exemplary 5G NR context.

[0039] FIG. 3 is a logical flow diagram illustrating one embodiment of a generalized method of PCI conflict resolution according to the present disclosure.

[0040] FIG. 3a is a logical flow diagram illustrating one embodiment of user device set identification within the generalized method of FIG. 3.

[0041] FIG. 3b is a logical flow diagram illustrating one embodiment of user device measurement reporting within the generalized method of FIG. 3.

[0042] FIG. 3c is a logical flow diagram illustrating a second embodiment of user device measurement reporting within the generalized method of FIG. 3.

[0043] FIG. 3d is a logical flow diagram illustrating one embodiment of whitelist/blacklist updating based on measurement reporting, within the generalized method of FIG. 3.

[0044] FIG. 4 is a functional block diagram of a first exemplary embodiment of an enhanced 5G NR network architecture according to the present disclosure.

[0045] FIG. 4a is a functional block diagram of a first exemplary implementation of the architecture of FIG. 4 within a non-roaming E-UTRAN/5G network architecture according to the present disclosure.

[0046] FIG. 4b is a functional block diagram of a second exemplary implementation of the architecture of FIG. 4 within a non-roaming E-UTRAN/5G network architecture according to the present disclosure.

[0047] FIG. 4c is a functional block diagram of a first exemplary implementation of the architecture of FIG. 4 within a roaming E-UTRAN/5G network architecture according to the present disclosure.

[0048] FIG. 5a is a functional block diagram of a first exemplary MSO/MNO network architecture useful in conjunction with various features described herein, wherein the MSO maintains the majority of 5G NR core infrastructure.

[0049] FIG. 5b is a functional block diagram of a second exemplary MSO/MNO network architecture useful in conjunction with various features described herein, wherein the MNO maintains the majority of 5G NR core infrastructure.

[0050] FIG. 6 is a functional block diagram illustrating a first exemplary embodiment of an HSS (Home Subscriber Service) and UDM (Unified Data Management), or HSS+UDM apparatus with PCI conflict resolution support, useful with various embodiments of the present disclosure.

[0051] FIG. 7 is a functional block diagram illustrating a first exemplary embodiment of an enhanced 3GPP-compliant 5G NR gNB apparatus with PCI conflict resolution capability, useful with various embodiments of the present disclosure.

FIGS. 3-7 © Copyright 2018-2019 Charter Communications Operating, LLC. All rights reserved. Other Figures © Copyright of their respective copyright holders.

DETAILED DESCRIPTION

[0052] Reference is now made to the drawings wherein like numerals refer to like parts throughout.

[0053] As used herein, the term “application” (or “app”) refers generally and without limitation to a unit of executable software that implements a certain functionality or theme. The themes of applications vary broadly across any number of disciplines and functions (such as on-demand content management, e-commerce transactions, brokerage transactions, home entertainment, calculator etc.), and one application may have more than one theme. The unit of executable software generally runs in a predetermined environment; for example, the unit could include a downloadable Java Xlet™ that runs within the JavaTV™ environment.

[0054] As used herein, the term “central unit” or “CU” refers without limitation to a centralized logical node within a wireless network infrastructure. For example, a CU might be embodied as a 5G/NR gNB Central Unit (gNB-CU), which is a logical node hosting RRC, SDAP and PDCP protocols of the gNB or RRC and PDCP protocols of the en-gNB that controls the operation of one or more gNB-DUs, and which terminates the F1 interface connected with one or more DUs (e.g., gNB-DUs) defined below.

[0055] As used herein, the terms “client device” or “user device” or “UE” include, but are not limited to, set-top boxes (e.g., DSTBs), gateways, modems, personal computers (PCs), and minicomputers, whether desktop, laptop, or otherwise, and mobile devices such as handheld computers, PDAs, personal media devices (PMDs), tablets, “phablets”, smartphones, and vehicle infotainment systems or portions thereof.

[0056] As used herein, the term “computer program” or “software” is meant to include any sequence or human or machine cognizable steps which perform a function. Such program may be rendered in virtually any programming language or environment including, for example, C/C++, Fortran, COBOL, PASCAL, assembly language, markup languages (e.g., HTML, SGML, XML, VoXML), and the like, as well as object-oriented environments such as the Common Object Request Broker Architecture (CORBA), Java™ (including J2ME, Java Beans, etc.) and the like.

[0057] As used herein, the term “distributed unit” or “DU” refers without limitation to a distributed logical node within a wireless network infrastructure. For example, a DU might be embodied as a 5G/NR gNB Distributed Unit (gNB-DU), which is a logical node hosting RLC, MAC and PHY layers of the gNB or en-gNB, and its operation is partly controlled by gNB-CU (referenced above). One gNB-DU supports one or multiple cells, yet a given cell is supported by only one gNB-DU. The gNB-DU terminates the F1 interface connected with the gNB-CU.

[0058] As used herein, the term “DOCSIS” refers to any of the existing or planned variants of the Data Over Cable Services Interface Specification, including for example DOCSIS versions 1.0, 1.1, 2.0, 3.0 and 3.1.

[0059] As used herein, the term “headend” or “backend” refers generally to a networked system controlled by an operator (e.g., an MSO) that distributes programming to MSO clientele using client devices, or provides other services such as high-speed data delivery and backhaul.

[0060] As used herein, the terms “Internet” and “internet” are used interchangeably to refer to inter-networks including, without limitation, the Internet. Other common examples include but are not limited to: a network of external servers, “cloud” entities (such as memory or storage not local to a device, storage generally accessible at any time via a network connection, and the like), service nodes, access points, controller devices, client devices, etc.

[0061] As used herein, the term “LTE” refers to, without limitation and as applicable, any of the variants or Releases of the Long-Term Evolution wireless communication standard, including LTE-U (Long Term Evolution in unlicensed spectrum), LTE-LAA (Long Term Evolution, Licensed Assisted Access), LTE-A (LTE Advanced), 4G LTE, WiMAX, VoLTE (Voice over LTE), and other wireless data standards.

[0062] As used herein, the term “memory” includes any type of integrated circuit or other storage device adapted for storing digital data including, without limitation, ROM, PROM, EEPROM, DRAM, SDRAM, DDR/2 SDRAM, EDO/FPMS, RLDRAM, SRAM, “flash” memory (e.g., NAND/NOR), 3D memory, and PSRAM.

[0063] As used herein, the terms “microprocessor” and “processor” or “digital processor” are meant generally to include all types of digital processing devices including, without limitation, digital signal processors (DSPs), reduced instruction set computers (RISC), general-purpose (CISC) processors, microprocessors, gate arrays (e.g., FPGAs), PLDs, reconfigurable computer fabrics (RCFs), array processors, secure microprocessors, and application-specific integrated circuits (ASICs). Such digital processors may be contained on a single unitary IC die, or distributed across multiple components.

[0064] As used herein, the terms “MSO” or “multiple systems operator” refer to a cable, satellite, or terrestrial network provider having infrastructure required to deliver services including programming and data over those mediums.

[0065] As used herein, the terms “MNO” or “mobile network operator” refer to a cellular, satellite phone, WMAN (e.g., 802.16), or other network service provider having infrastructure required to deliver services including without limitation voice and data over those mediums. The term “MNO” as used herein is further intended to include MVNOs, MNVAs, and MVNEs.

[0066] As used herein, the terms “network” and “bearer network” refer generally to any type of telecommunications or data network including, without limitation, hybrid fiber coax (HFC) networks, satellite networks, telco networks, and data networks (including MANs, WANs, LANs, WLANs, internets, and intranets). Such networks or portions thereof may utilize any one or more different topologies (e.g., ring, bus, star, loop, etc.), transmission media (e.g., wired/RF cable, RF wireless, millimeter wave, optical, etc.) and/or communications technologies or networking protocols (e.g., SONET, DOCSIS, IEEE Std. 802.3, ATM, X.25, Frame Relay, 3GPP, 3GPP2, LTE/LTE-A/LTE-U/LTE-LAA, SGNR, WAP, SIP, UDP, FTP, RTP/RTCP, H.323, etc.).

[0067] As used herein the terms “5G” and “New Radio (NR)” refer without limitation to apparatus, methods or systems compliant with 3GPP Release 15, and any modifications, subsequent Releases, or amendments or supplements thereto which are directed to New Radio technology, whether licensed or unlicensed.

[0068] As used herein, the term “QAM” refers to modulation schemes used for sending signals over e.g., cable or other networks. Such modulation scheme might use any constellation level (e.g. QPSK, 16-QAM, 64-QAM, 256-QAM, etc.) depending on details of a network. A QAM may also refer to a physical channel modulated according to the schemes.

[0069] As used herein, the term “server” refers to any computerized component, system or entity regardless of form which is adapted to provide data, files, applications, content, or other services to one or more other devices or entities on a computer network.

[0070] As used herein, the term “storage” refers to without limitation computer hard drives, DVR device, memory, RAID devices or arrays, optical media (e.g., CD-ROMs, Laserdiscs, Blu-Ray, etc.), or any other devices or media capable of storing content or other information.

[0071] As used herein, the term “Wi-Fi” refers to, without limitation and as applicable, any of the variants of IEEE Std. 802.11 or related standards including 802.11 a/b/g/n/s/v/ac/ax, 802.11-2012/2013 or 802.11-2016, as well as Wi-Fi Direct (including inter alia, the “Wi-Fi Peer-to-Peer (P2P) Specification”, incorporated herein by reference in its entirety).

Overview

[0072] In one exemplary aspect, the present disclosure provides methods and apparatus for, inter alia, effectively resolving conflicts in PCI values which may exist within two or more mobile networks (e.g., PLMNs) of respective different operators when unlicensed spectrum is utilized.

[0073] In one implementation, this functionality is provided by specifying one or more mobility-related parameters associated with various UE, such that serving gNBs can determine whether a given UE requires a mobility context, and as such whether it should conduct subsequent RF measurement reporting to report back potential conflicts in PCI it may encounter to the gNB. In one variant, the measurement reporting is configured to comply with 5G NR-U required “listen-before-talk” or LBT protocols; i.e., to measure parameters consistent with the LBT protocols as part of the detection of any such PCI-based conflicts.

[0074] In another variant, a maximum number of PLMNs common to a given PCI is specified, such that instructed UE(s) will limit themselves to measurement reporting on that number of detected PLMNs.

[0075] Enhanced PCI confusion resolution capability as described herein advantageously allows for UE to utilize unlicensed spectrum (e.g., under the NR-U model) without complicated network communication and configuration requirements between two or more operating networks as typically found in licensed spectrum scenarios.

[0076] Moreover, the various aspects of the present disclosure can be implemented within the existing base of UE with no modification; i.e., each UE merely uses existing RF measurement reporting functions to provide the necessary data back to the serving gNB for PCI conflict resolution.

[0077] Similarly, only minor modifications to extant network-side architectures (e.g., 3GPP) are needed to support this enhanced functionality.

Detailed Description of Exemplary Embodiments

[0078] Exemplary embodiments of the apparatus and methods of the present disclosure are now described in detail. While these exemplary embodiments are described in the context of the previously mentioned wireless access networks (e.g., 5GS and ECS) associated with or supported at least in part by a managed network of a service provider (e.g., MSO and/or MNO networks), other types of radio access technologies (“RATs”), other types of networks and architectures that are configured to deliver digital data (e.g., text, images, games, software applications, video and/or audio) may be used consistent with the present disclosure. Such other networks or architectures may be broadband, narrowband, or otherwise, the following therefore being merely exemplary in nature.

[0079] It will also be appreciated that while described generally in the context of a network providing unlicensed spectrum service to a customer or consumer or end user or subscriber (i.e., within a prescribed service area, venue, or other type of premises), the present disclosure may be readily adapted to other types of environments including, e.g., outdoors, commercial/retail, or enterprise domain (e.g., businesses), or even governmental uses (including e.g., quasi-licensed spectrum such as CBRS). Yet other applications are possible.

[0080] Other features and advantages of the present disclosure will immediately be recognized by persons of ordinary skill in the art with reference to the attached drawings and detailed description of exemplary embodiments as given below.

Methods

[0081] Referring now to FIGS. 3-3C, various embodiments of the methods of, inter alia, cell identification and operating a wireless network, are shown and described in detail. It will be appreciated that while these methods are described primarily in the context of a 3GPP-based (i.e., E-UTRAN and 5G NR) architecture, the various methods are in no way so limited, and may be readily adapted and applied to other types or configurations of wireless network such as for instance MulteFire™-based networks, such adaptation and application being within the skill level of the ordinary artisan given the present disclosure.

[0082] FIG. 3 shows a first embodiment of the generalized method for cell identification according to the present disclosure. Per step 302 of the method 300, one or more candidate UE(s) for PCI confusion resolution are identified. As described in greater detail below, in one implementation, this identification is accomplished based on a mobility-related factor or determination.

[0083] Next, per step 304, the cognizant gNB instructs the identified set of UEs from step 302 to perform Measurement Reports. As discussed below, in one implementation, the Measurement Reports are conducted taking the LBT (Listen Before Talk) protocol into account.

[0084] Lastly, per step 306, the gNB uses data from the Measurement Reports provided by the UE(s) to update the current white and/or black lists to include/exclude unrelated or improper PCI values.

[0085] Referring now to FIG. 3a, one particular implementation of step 302 of the method 300 is shown. Specifically, within step 302 of the method 300, a mobility-related determination is performed. Specifically, the gNB identifies at least some of the candidate set of UEs as requiring or not requiring application of the confusion resolution mechanism based on the presence or absence of a prescribed parameter (in one variant, the value “No Mobility Required” or NMR is used, although other values and forms of parameter may be used with equal success. Specifically, for certain UE(s) such as those used for Fixed Wireless Access (FWA), no mobility scenarios exist and hence such scenarios need not be supported. If a given gNB can identify such UE(s), then it can request the identified UE(s) to not perform Measurement Reports for certain PCI(s).

[0086] In one approach, the presence or absence of this NMR or similar parameter is conducted when such UE(s)/users perform registration with the 5GC (see 3GPP TS 23.501, and 23.502); i.e., the “No Mobility Required” value is present in the N2-AP INITIAL CONTEXT SETUP REQUEST (which carries Registration Accept per TS 23.502 Section 4.2.2.2.2, step 21); see also TS 38.413 Section 8.3.1.2, step 2, each of the foregoing incorporated herein by reference in its entirety. Specifically, the AMF (Access and Mobility Management Function) may initiate the Initial Context Setup procedure if (i) a UE-associated logical NG-connection exists for the UE, or (ii) if the AMF has received the RAN UE NGAP ID IE in an INITIAL UE MESSAGE message, or (iii) if the NG-RAN node has already initiated a UE-associated logical NG-connection by sending an INITIAL UE MESSAGE message via another NG interface instance. The procedure uses UE-associated signalling.

[0087] Hence, per step 312 of the method of FIG. 3a, the AMF accesses the UE/subscription data for the relevant UE (e.g., by accessing the global DB 402 at the HSS+UDM entity 401 discussed below), and inserts this accessed data into the relevant context message (e.g., CONTEXT SETUP REQUEST) transmitted to the cognizant gNB (step 314).

[0088] To support the presence or absence of this NMR parameter within the above registration process, in one variant, each UE is characterized at time of generation of the UE(s) and/or users' subscription profile within the UDM (Unified Data Management) process or entity, the profile denoting “No Mobility Required” for that UE/user. For instance, an end-user may be utilizing a fixed 5G-enabled wireless device such as a smart TV, DSTB, gateway, router, IoT-enabled device, etc. which has no mobility capability.

[0089] As a brief aside, it will be recognized that as used herein, the term “mobility” refers more to intra-cell mobility, versus inter-cell mobility. Specially, any device is mobile to some degree; i.e., one can set up their smart TV or IoT device within their premises, and then later move it to another location within the same premises. However, under such scenarios, from a PCI perspective, the device is immobile. Notwithstanding, the present disclosure also contemplates use of two or more “grades” or levels of mobility characterization in one alternate embodiment; e.g., (i) No Mobility Required, (ii) Limited Mobility Required, and (iii) Full Mobility Required. Under such model, the gNB can apply different protocols to the different levels of mobility support needed; e.g., the method 300 above for NMR, another for LMR (e.g., a hybridization of the method of FIG. 3 and mobility-enabled approaches in scenarios where the UE or another gNB signals that it then requires mobility in that limited instance), and yet another for FMR scenarios.

[0090] It will also be appreciated that while the foregoing approach of accessing the UDM (e.g., via the AMF) as part of the Attach procedure (and generating the INITIAL CONTEXT SETUP REQUEST sent to the gNB with mobility-related data) is used to determine UE mobility status for purposes of PCI management, other approaches may be used consistent with the present disclosure. For example, in another variant, the UE itself supplies the NMR or other parameter, such as via another Attach procedure or setup message.

[0091] As yet another variant, the parameter(s) of interest (e.g., NMR) may be provided in RRC signaling between the UE and gNB, including in some cases coupling with a subscription-based solution (the latter which is advantageously reliable and operator-controllable) as described in greater detail below with respect to Appendix II. Referring again to FIG. 3a, the gNB, upon receiving the context message from the AMF (step 316), analyzes the message and extracts the NMR value if present, and stores the NMR value for the duration of the UE's session context (i.e., during RRC CONNECTED and RRC INACTIVE states) per step 318. As described in greater detail below, the gNB may use the NMR data e.g., when deciding to request one or more UE(s) to perform Measurement Reporting, and correspondingly update white/black lists for Measurement Reporting if deemed necessary

[0092] It will also be recognized that in other variants, the NMR or other mobility-related data may be used as a basis for inclusion as well as exclusion of UEs within the gNB identification logic. For example, if it is desired to identify UE(s) with no mobility requirements, then those carrying the NMR parameter (e.g., via the CONTEXT REQUEST from the AMF as described above) are included, and all else are excluded. Conversely, if it is desired to identify only UE(s) having mobility requirements, those carrying the NMR parameter are excluded, and all else included. It will be recognized that the “negative” of this approach can be used as well consistent with the present disclosure; i.e., all UE(s) not within a FWA or no-mobility context can have for instance an “MR” (Mobility Required) parameter, while all others have no such value. Likewise, in another variant, those UE(s) requiring mobility may carry the MR parameter, while those under FWA carry the NMR parameter. Since the number of FWA-context devices is expected to be much less than the mobility-required devices, it is more efficient to merely label the FWA-context devices with NMR or the like in such scenarios. In one implementation, UEs not supporting NMR functionality by definition will be considered normal UEs, although it will be recognized that they may also be affirmatively identified or labeled as not supporting parameter (e.g., NMR) functionality.

[0093] Referring now to FIG. 3b, one implementation of step 304 of the method 300 of FIG. 3 is described. Specifically, per step 320, the cognizant gNB determines at least one “target” PCI, as well as a duration value specifying the duration for which the requested measurement is to be performed (i.e., in order to sufficiently collect required NCGI data from all PLMNs broadcasting the same PCI for a given frequency) per step 322. As noted, for a given cell, a gNB supports many UEs. Based on those UEs' mobility state information already available the gNB (e.g., the NMR parameter), the gNB requests the identified sub-set of UEs to perform (or not perform, depending on the constitution of the sub-set as discussed supra) additional Measurement Reports to resolve PCI confusion. In one such approach, the gNB affirmatively instructs only those UE not having the NMR parameter associated to perform the Measurement Reports. In another approach, the gNB affirmatively instructs only those UE having the NMR parameter associated to not perform the Measurement Reports.

[0094] As a brief aside, unlicensed spectrum coexistence is a key principle in both LAA (LTE) and NR-U (5G). This coexistence is accomplished by dynamically selecting available channels within the unlicensed band to avoid e.g., Wi-Fi users. If no available or clear channel is present, channels are shared “fairly” among the users using the Listen Before Talk (LBT) protocol. As in LTE-LAA and other technologies, the LBT protocol in NR-U is a mechanism by which measurements of a given carrier are obtained, and use or “backoff” determined based on the measurements.

[0095] Accordingly, in one implementation, step 324 of FIG. 3b includes the following ASN.1 additions to the MeasObjectNR IE (information element which specifies information applicable for SS/PBCH block(s) intra/inter-frequency measurements or CSI-RS intra/inter-frequency measurements) to instruct the UE(s) on the requisite scan time (including flexibility to change as needed dynamically)—see Appendix I hereto:

TABLE-US-00004  measReportLBTScanTime  INTEGER (XX..maxMeasRepPCIScanTime) OPTIONAL -- Time for which the UE scans for all possible SSBs being broadcasted in the same PCI by different PLMNs  maxMeasRepPCIScanTime  INTEGER ::= YY  (where YY is the Maximum time (in ms) for which a given PCI is scanned)

[0096] As a brief aside, in 5G NR, the SSB (the Synchronization Signal/PBCH Block) consists of synchronization signal (i.e., PSS and SSS) and PBCH channels. The SSB burst set is re-transmitted every 5 ms, and within every SSB burst set the SSB is transmitted at a certain periodicity. Since SSB is unique to a gNB on a per-cell, per-beam basis, it is safe to assume that when the SSB is transmitted continuously over a physical medium (e.g., an RF frequency), within a 5 ms period, a UE looking for the SSB should be able to read it.

[0097] In that NR requires tight time synchronization between the gNB and UE, it is also safe to assume that multiple gNBs both within the same PLMN and across different PLMNs are coordinated to an accurate timing source (e.g., atomic clock). Hence, time deviation among the gNBs of different PLMNs is negligible.

[0098] In LTE-LAA, the maximum COT (channel occupancy time) following a successful LBT procedure is 10 ms (see TS 37.213 v15.1.0 clause 4.1.1, incorporated herein by reference in its entirety). One implementation of the methodology described herein, based on the assumption that an NR system uses the same 10 ms value, uses a 15 ms total (5 ms+10 ms) time for the UE to scan for all possible SSBs being broadcast in the same PCI, such as by different PLMNs. As such, the previously discussed ASN.1 additions to the MeasObjectNR IE in such implementations can be configured with values of XX and YY of 5 ms and 15 ms, respectively—that is:

TABLE-US-00005  measReportLBTScanTime  INTEGER (5..maxMeasRepPCIScanTime) OPTIONAL -- Need R  maxMeasRepPCIScanTime INTEGER ::= 15
Hence, per step 324 of FIG. 3b, the gNB then provides the identified UE(s) from step 302 (FIG. 3) with the determined PCI and scan time values as above, which enables the UE to scan the PCI(s) and return the generated data as part of the Measurement Report procedure.

[0099] Per step 326, the gNB extracts the relevant reporting data for the target PCI values from the Measurement Reports of the “instructed” UE after such Reports have been received (e.g., signal strength data for the prescribed frequencies).

[0100] In another implementation (discussed below with respect to FIG. 3c), the gNB further instructs the UE(s) to implement a second parameter relating to a prescribed maximum number of PLMNs to report on.

[0101] Referring now to FIG. 3d, one implementation of the method step 306 of FIG. 3 is now described in detail. As shown, per step 330, the gNB assembles the extracted Measurement Report data from the directed UE(s) relating to all NCGI(s), in response to gNB's PCI to NCGI resolution request. In one variant, this is performed on a per-PCI basis, although other schemes may be utilized consistent with the present disclosure.

[0102] Per step 332, the gNB logic then evaluates the received data for each target PCI to determine whether conflicts are present. Per steps 334 and 336 the gNB can, based on various criteria including the results of the evaluation of step 332, decide to update the current white list and/or black list; i.e., specifying those PCI on which it wishes to subsequently obtain Measurement Reports.

[0103] Notably, extant white list/black list approaches only allow for the inclusion of PCI values (i.e., in the PCI-Range IE). The PCI-Range IE is defined in TS 38.331 and is used to encode either a single or a range of physical cell identities. Per TS 38.331, the range is encoded by using a start value and by indicating the number of consecutive physical cell identities (including start) in the range. For fields comprising multiple occurrences of PCI-Range, the Network may configure overlapping ranges of physical cell identities. The “range” field in the PCI-Range IE indicates the number of physical cell identities in the range (including start). For example, the value n4 corresponds with 4, n8 corresponds with 8. The UE applies a value of 1 in the case the field is absent, in which case only the physical cell identity value indicated by the “start” field applies. The “start” field indicates the lowest physical cell identity in the range.

[0104] In the particular case of PCI confusion, however, the extant structure is not sufficient. Specifically, what is required is the ability to either enable or disable Measurement Reports from PCI(s) of a specific PLMN. Therefore, the following modified ASN.1 PCI-Range IE is provided per one embodiment of the present disclosure to support such additional specificity:

TABLE-US-00006 Modified PCI-Range Information Element -- ASN1START -- TAG-PCI-RANGE-START PCI-Range ::=   SEQUENCE {  start PhysCellId,  range  ENUMERATED {n4, n8, n12, n16, n24, n32, n48, n64, n84,    n96, n128, n168, n252, n504, n1008,spare1} OPTIONAL --Need S   nrCellId  CellGlobalIdNR OPTIONAL -- PCIs of specific PLMNs for which Measurements Reports are to be disabled } CellGlobalIdNR ::=  SEQUENCE {   plmn-Identity     PLMN-Identity,   cellIdentity     CellIdentity } -- TAG-PCI-RANGE-STOP -- ASN1STOP

[0105] As referenced above, in another variant, the parameter(s) of interest (e.g., NMR) may be provided in RRC signaling between the UE and gNB, including in some cases coupling with a subscription-based solution (the latter which is advantageously reliable and operator-controllable). For example, in one implementation, the UE provides the parameter(s) (e.g., NMR) within the UE NR-Capability IE, which is included in UECapabilityInformation message (the latter which is sent in response to UECapabilityInquiry message). As such, relevant portions of TS 38.331 may be modified as described below.

[0106] Specifically, upon reception of the foregoing data, the cognizant gNB has an understanding of whether a given UE can support the parametric determination (e.g., NMR) or not. Combined with the information received over the N2-AP INITIAL CONTEXT SETUP REQUEST as described elsewhere herein, the gNB can accurately decide whether or not to apply NMR for this UE. In one implementation, within the exemplary UECapability Information IE, the UE-CapabilityRAT-ContainerList is used. The IE UE-CapabilityRAT-ContainerList contains a list of radio access technology specific capability containers. For NR, the IE UE NR-Capability IE is used to convey the NR UE Radio Access Capability Parameters, see TS 38.306. Appendix II hereto illustrates an exemplary implementation of the UE NR-Capability IE including added NMR parameters according to the present disclosure.

[0107] In another embodiment of the methodology (see FIG. 3c), the gNB may also utilize a second parameter to control the behavior of the UE conducting the measurement reporting. This second parameter, as described in greater detail below, may be used in tandem with (or even in place of in some circumstances) the previously described timing duration parameter(s).

[0108] Specifically, it is recognized by the inventors hereof that there is no reliable mechanism for knowing a priori how many PLMN operators will be operating within a given cell's area at any given point in time. During the initial deployment phase of NR technology, it is expected that the number of PLMN operators will be comparatively small and contained; however, as deployment continues over time, this assumption may no longer hold true. As discussed above, the ability of the gNB to utilize scan time limit(s) which may be applied to the PCI search and reporting is already provided herein. However, it may be the case e.g., that the use of the time-bounded limit may not be sufficient to adequately restrict the measurement reporting conducted by the UE; i.e., if a larger number of PLMNs are present (e.g., more than 5), they may all be within the prescribed scan window, including in some cases being “densely packed” within a smaller portion of the scan window due to e.g., statistical variation, and hence the UE would still be conducting a higher number of scans/reports than desired, even with the scan window limit imposed.

[0109] As such, an additional mechanism by which the number of PLMNs corresponding to the PCI (and hence reports corresponding thereto generated by the UE(s)) may be limited is proposed herein; i.e., a “report-bound” in addition to the previously described “time-bound” on the PLMN search. Specifically, in one implementation, an addition to the ASN.1/TS 38.331 MeasObjectNR IE is used as shown below:

[0110] maxPLMNsPerPCIToReport INTEGER ::=(1..maxNrOfPLMNsPerPCIToReport) OPTIONAL—Maximum number of PLMNs for the same PCI for Measurement reports are to be generated by the UE

[0111] In one implementation, the constant maxNrOfPLMNsPerPCIToReport is defined as follows:

[0112] maxNrOfPLMNsPerPCIToReport INTEGER ::=20

[0113] Appendices III and IV hereto illustrate various embodiments of the use of the above value within the ASN.1 MeasObjectNR IE.

Note also that in Appendix IV, the following elements have been added in place of the CellGlobalNR IE of the alternate embodiment:

TABLE-US-00007 blackCellsToAddModList BlockPCIOfCertainPLMNs blackCellsToRemoveList BlockPCIOfCertainPLMNs
Note also that in Appendix IV, several new elements have been added, including e.g., the following:

TABLE-US-00008 BlockPCIOfCertainPLMNs::= SEQUENCE {  cellIdentity  CellIdentity  plmn-Identity  PLMN-Identity

[0114] Referring again to FIG. 3c, the method proceeds similar to that of FIG. 3b described supra; however, at step 323, the further gNB determines the maximum number of PLMNs (e.g., 5 as in the example above) for which measurement reporting is to be conducted by the UE. This determined value may be on a global basis (i.e., all UE), or individual to one or more UE within the broader population.

[0115] Per step 325, the gNB instructs the relevant UE(s) with the target PCI value(s), duration(s), and also maximum PLMN number selected per step 323.

[0116] It will be appreciated that the exemplary specified constant value above (5) may be varied as needed, based on operational or other considerations. This variation may even be dynamic in nature, such as e.g., by logic having insight into the number of active PLMNs as a function of time (which may be correlated for example to status of operational deployment, planned maintenance outages, etc.). The value of the constant may also be related to the above-described scan time value(s), such as where it is desired to use the maxNrOfPLMNsPerPCIToReport parameter to limit the measurement reporting when a longer scan time window is used (i.e., when the window is so long as to effectively provide no limitation).

[0117] It will also be appreciated that the scan time parameter(s) and the maximum number of PLMN parameter may be used heterogeneously across different UE being served by a common gNB. For instance, it may be desirable in some cases to have one subset of the UE population implement the scan time parameter(s) alone, while others utilize the combination of scan time and maximum PLMN number parameters. Since RRC parameters are UE-specific, different UEs can be provided different values by the gNB given its knowledge of the topology, statistics, operational considerations, etc. These heterogeneous uses may also be combined with the conjunctive/selective use of the scan time and maximum PLMN numbers described herein to optimize the network on a per-UE/per-gNB basis. For example, even two UE's within the same subset may have differing combinations/constant values, such as in the case where Combination A (scan time parameter=R, maximum PLMN number=S) is applied to a portion of the second subset mentioned above (combination subset), while Combination B (scan time parameter=T, maximum PLMN number=U) is applied to another portion of that same second subset.

[0118] Further, as referenced above, the present disclosure contemplates use of individual ones of the parameters (e.g., scan time/maximum number of PLMNs) either individually or in combination, depending on factors such as operational circumstance. It will be appreciated that such different parameters may have respective different benefits/optimizations, thereby making their use non-identical. For instance, one risk or potential detriment of using the scan time parameter alone is that the cognizant gNB may not get an accurate representation of all possible combinations of PLMNs which a given UE is experiencing. This disability can be resolved by, for instance, the gNB performing cell scans itself, or performing ANR, but, neither of these “work arounds” is optimal.

[0119] Conversely, one risk or potential detriment in using the maximum PLMN number parameter alone is that as the number of PLMNs for a given PCI increases, the affected UE(s) will spend progressively longer times (and resources) scanning for all possible PLMNs (i.e., until the maximum specified number is reached).

[0120] Accordingly, in one exemplary implementation of the disclosure, a conjunction of both parameters may provide an optimal balance of UE power consumption obtaining the most accurate data regarding the UE's environment. It will be recognized, however, that such uses may be selectively invoked or adjusted; for instance, where UE electrical power consumption is low (e.g., where the battery charge is significantly depleted or below a prescribed threshold), this information may be used to “rebalance” the optimization, such as by e.g., reducing the maximin number of PLMNs specified in the constant maxNrOfPLMNsPerPCIToReport.

[0121] In yet another embodiment of the disclosure, rather than use of CGI reporting—e.g., cgi-Info IE in MeasResultNR (which may or may not be active based on circumstance; i.e., is optional, and CGI reporting may not be turned on), the PLMN-ID is reported when performing RSRQ/RSRP or other signal strength indicator (SSI) measurements, based on PCI reporting.

[0122] Specifically, as shown in the embodiment of Appendix III, the PLMN-ID may be added to MeasResultNR, so that the PLMN-ID can be obtained in cases where CGI reporting is not invoked. Alternatively, it can be obtained from the CGI-nfo IE where utilized.

Network Architecture

[0123] FIG. 4 shows one embodiment of a 5G NR-based architecture 400, including aspects as defined in 3GPP TS 23.501, according to the present disclosure. Specifically, as shown, the architecture 400 includes a UDM-based data repository or database 402 of UE characterizing data (such as for instance the NMR and/or other parameters previously described) to be used consistent with the methods of FIGS. 3-3C. The architecture also includes a PCI Conflict Resolution Entity (PCRE) 404, as well as a local characterizing database 406 for all or a subset of the gNBs (within the NG-RAN). For example, in one scenario, all RAN (and their gNBs) include a PCRE 404 and database 406. In another scenario, only gNBs supporting particular unlicensed spectrum functionality include the PCRE/database. In yet another scenario, gNBs expected to have significant PCI conflicts (e.g., by virtue of having a large unlicensed footprint or presence nearby or overlapping within the RAN coverage area) include the PCRE/database. It will be appreciated that any number of deployment configurations and scenarios may be utilized consistent with the present disclosure, the architecture 400 of FIG. 4 being merely exemplary.

[0124] FIG. 4a is a functional block diagram of a first exemplary embodiment of an enhanced E-UTRAN/5G network architecture according to the present disclosure. Specifically, as shown in FIG. 4a, the architecture 400 includes generally both a legacy or 4G/4.5G RAN 422 and a 5G-NR RAN (NG-RAN) 424, although it will be appreciated that configurations with different numbers of and/or other types of RANs may be utilized consistent with the present disclosure; e.g., a given PLMN may have multiple RANs including mixtures of legacy and next-generation technology, as well as unlicensed (e.g., ISM-band) and/or quasi-licensed (e.g., CBRS) apparatus and a capability associated therewith. In the illustrated embodiment, the PLMN represented within the diagram is the home PLMN (HPLMN) of the 5G NR-U enabled UE.

[0125] As shown, the 5G RAN 424 of the type described subsequently herein in detail is configured to include both a local parameter (e.g., NMR in this example) database 406, and PCRE 404. In this embodiment, the PCRE/NMR database are located within the 5G NR CU (central unit) of the relevant gNBs (not shown), although it will be appreciated that these components may be located in different locations, whether individually or collectively.

[0126] Also shown is the global NMR database 402, here logically disposed within the HSS+UDM functionality of the SGC. The N8 interface as shown enables communication between the UDM process (and hence the global DB 402) and the serving AMF 426 in support of the PCI confusion resolution functions described herein.

[0127] In the architecture 440 of FIG. 4b, the PCRE 404 and local NMR database 406 are disposed logically within the AMF function 446, and hence multiple CU/DU (gNBs) can be provided with the PCI conflict resolution function more centrally as opposed to the configuration of FIG. 4a. In order for each gNB to receive and process the NMR data, a client or local portion of the PCRE (PCRE.sub.cl) 442 and server portion (PCRE.sub.s) 444 are used, with the PCRE.sub.s performing the evaluation and determination logic of e.g., FIGS. 3-3c, and the PCRE.sub.cl merely acting as an “implementation minion” process to in effect configure various UE with which it is in contact for Measurement Reporting (or no such reporting) as required.

[0128] In the architecture 460 of FIG. 4c, the PCRE.sub.s 444 is disposed within HSS+UDM of the UE's home PLMN, while the client (PCRE.sub.cl) 442 is disposed within the visited PLMN (i.e., within the CU/DU of the NG-RAN gNB(s)). The local NMR DB 406 is obviated in favor of a single global DB 402 at the HSS+UDM.

[0129] As discussed with respect to FIGS. 5a and 5b below, depending on the division of ownership/operational responsibility between the NR (licensed) and NR-U (unlicensed) infrastructure, various combinations of component placement and configuration are possible in supporting the PCI conflict resolution functionality. For instance, in one variant, an MSO (e.g., cable or satellite network operator) may maintain NG-RAN functionality within their service domain (such as via their own deployed “standalone” or SA 5G NR-U enabled gNBs, as well as other unlicensed and/or quasi-licensed devices such as Wi-Fi APs, CBRS CBSDs, etc., with which the NR-U functionality must co-exist. Alternatively, in another variant, the MNO (e.g., cellular service provider) may maintain all infrastructure (including the PCI conflict resolution enabled gNBs and the various NMR databases), and merely lease or otherwise enable customers of the MSO to access the MNO infrastructure.

[0130] As such, the placement and configuration of the various PCI conflict resolution processes (i.e., PCREs, NMR databases, etc.) is envisioned to vary accordingly. Advantageously, since standardized 5G NR protocols and interfaces are utilized, communication between the various entities is straightforward (i.e., as opposed to proprietary protocols utilized in each domain).

Service Provider Network

[0131] FIG. 5a illustrates a typical service provider network configuration useful with the features of the enhanced PCI conflict resolution apparatus and methods described herein, including the enhanced 3GPP architectures of FIGS. 4-4c. This service provider network 500 is used in one embodiment of the disclosure to provide backbone and backhaul from the service provider's service nodes, such as HFC cable or FTTC/FTTH drops to different premises or venues/residences. For example, one or more stand-alone or embedded DOCSIS cable modems (CMs) 512 are in data communication with the various NR (5G) architecture components (e.g., DU's and CU's) so as to provide two-way data communication to the served components.

[0132] Also provided within the architecture 500 of FIG. 5 is an MSO interface 532 to one or more MNO networks 511, such as those of an MVNO. The exemplary MNO/MVNO infrastructure or domain includes a number of 3GPP gNBs 544a-b and eNBs as shown, thereby providing 3GPP 4G/4.5G/5G coverage to authorized users of the MNO/MNVO network. These components (and others needed to support the E-UTRAN and 5G RAN in the architecture of e.g., FIG. 4a, such as the SGW and MME/MME.sub.e—not shown in FIG. 5) interface with the MSO-domain (and ultimately the HSS+UDM with global NMR DB) via e.g., a data interface 550 to the MSO backbone 531. In one embodiment, this interface 532 supports the S5/S8/S6a 3GPP interfaces between the S-GW and P-GW (S8 is used when roaming between different operators, while S5 is network-internal).

[0133] The UE may include two radio transceivers (one for 3GPP LTE, and one for 3GPP NR including NR-U), or alternatively a common unified dual-mode transceiver, as well as protocol stacks serving the respective transceivers for functions including support of higher layer processes such as authentication.

[0134] Also included in the infrastructure 500 of FIG. 5a are the HSS+UDM with global NMR DB 402, PGW, h-PCF/h-PCRF, AMF 426, v-PCF, v-SMF, and UPF entities of FIGS. 4-4c. While these entities are shown as part of the MSO “core” infrastructure portion in this embodiment, it will be appreciated as previously discussed that such entities each (i) may be distributed at two or more different/other locations within the MSO core or service domain(s); (ii) may be combined with each other or with other MSO infrastructure components (including those at the service domain), and (iii) may be virtualized as software/firmware processes within other components (such as MSO system servers, RAN infrastructure, etc.). Hence, the illustrated configuration of FIG. 5a is merely illustrative in this regard.

[0135] Moreover, it will be recognized that while the architecture 500 of FIG. 5a is characterized in the context of the embodiment of FIG. 4a (i.e., with the PCRE functionality logically and functionally contained within the gNBs of the MSO service domain, the architecture 500 may readily be adapted by those of ordinary skill given the present disclosure for other embodiments, including for example those of FIGS. 4b and 4c.

[0136] In certain embodiments, the service provider network architecture 500 also advantageously permits the aggregation and/or analysis of subscriber- or account-specific data (including inter alia, particular CU or DU or E-UTRAN eNB/femtocell devices associated with such subscriber or accounts, as well as their mobility or FWA status as previously discussed) as part of the provision of services to users under the exemplary delivery models described herein. As but one example, device-specific IDs (e.g., gNB ID, Global gNB Identifier, NCGI, MAC address or the like) can be cross-correlated to MSO subscriber data maintained at e.g., the network head end(s) 507, or within the HSS+UDM (and associated global NMR database 402) where maintained by the MNO, so as to permit or at least facilitate, among other things, PCI conflict resolution and Measurement Report configuration.

[0137] As a brief aside, a number of additional identifiers over and above the PCI discussed supra are used in the NG-RAN architecture, including those of UE's and for other network entities. Specifically:

[0138] the AMF Identifier (AMF ID) is used to identify an AMF (Access and Mobility Management Function 426 shown in FIGS. 4-4c);

[0139] the NR Cell Global Identifier (NCGI), is used to identify NR cells globally, and is constructed from the PLMN identity to which the cell belongs, and the NR Cell Identity (NCI) of the cell;

[0140] the gNB Identifier (gNB ID) is used to identify gNBs within a PLMN, and is contained within the NCI of its cells;

[0141] the Global gNB ID, which is used to identify gNBs globally, and is constructed from the PLMN identity to which the gNB belongs, and the gNB ID;

[0142] the Tracking Area identity (TAI), which is used to identify tracking areas, and is constructed from the PLMN identity to which the tracking area belongs, and the TAC (Tracking Area Code) of the Tracking Area; and

[0143] the Single Network Slice Selection Assistance information (S-NSSAI), which is used to identify a network slice.

Hence, depending on what data is useful to the MSO or its customers, various portions of the foregoing can be associated and stored to particular gNB “clients” or their components being backhauled by the MSO network.

[0144] The MSO network architecture 500 of FIG. 5a is particularly useful for the delivery of packetized content (e.g., encoded digital content carried within a packet or frame structure or protocol, such as video, audio, or voice data) consistent with the various aspects of the present disclosure. In addition to on-demand and broadcast content (e.g., live video programming), the system of FIG. 5 may deliver Internet data and OTT (over-the-top) services to the end users (including those of the DU's 506a-c) via the Internet protocol (IP) and TCP (i.e., over the 5G radio bearer), although other protocols and transport mechanisms of the type well known in the digital communication art may be substituted.

[0145] The network architecture 500 of FIG. 5a generally includes one or more headends 507 in communication with at least one hub 517 via an optical ring 537. The distribution hub 517 is able to provide content to various “client” devices 509a, 506a-c, and gateway devices 560 as applicable, via an interposed network infrastructure 545. It will be appreciated from examination of FIG. 5a that the various gNB components (including the NR DU's and CU's and their constituent UE.sub.e's) may each act as a “client” device of the network. For example, in many installations, the CU 504 of a given gNB is physically disparate or removed from the locations of its constituent DU's 506, and hence an interposed (e.g., wired, wireless, optical) PHY bearer is needed to communicate data between the DU's and CU of a given gNB. In one such architecture, the CU may be placed further toward the core of the MSO distribution network, while the various constituent DU's are placed at the edge. Alternatively, both devices may be near the edge (and e.g., served by edge QAMs or RF carriers 540 as shown in FIG. 5a). In both cases, the MSO infrastructure may be used to “backhaul” data from each device and communicate it to, via the MSO infrastructure, the other components, much as two geographically disparate customers of a given MSO might communicate data via their respective DOCSIS modems in their premises. Each component has an IP address within the network, and as such can be accessed (subject to the limitations of the architecture) by the other components.

[0146] Alternatively, the CU's (which in effect aggregate the traffic from the various constituent DU's towards the NG Core), may have a dedicated high bandwidth “drop.”

[0147] Moreover, a given CU and DU may be co-located as desired, as shown by the combined units 504b and 504c, and 506b and 506c in FIG. 5a. This may also be “hybridized,” such as where one constituent DU is co-located (and potentially physically integrated) with the CU, while the remaining DU of that CU are geographically and physically distributed.

[0148] In the MSO network 500 of FIG. 5a, various content sources 503, 503a are used to provide content to content servers 504, 505 and origin servers 521. For example, content may be received from a local, regional, or network content library as discussed in co-owned U.S. Pat. No. 8,997,136 entitled “APPARATUS AND METHODS FOR PACKETIZED CONTENT DELIVERY OVER A BANDWIDTH-EFFICIENT NETWORK”, which is incorporated herein by reference in its entirety. Alternatively, content may be received from linear analog or digital feeds, as well as third party content sources. Internet content sources 503a (such as e.g., a web server) provide Internet content to a packetized content origin server(s) 521. Other IP content may also be received at the origin server(s) 521, such as voice over IP (VoIP) and/or IPTV content. Content may also be received from subscriber and non-subscriber devices (e.g., a PC or smartphone-originated user made video).

[0149] The network architecture 500 of FIG. 5a may further include a legacy multiplexer/encrypter/modulator (MEM; not shown). In the present context, the content server 504 and packetized content server 521 may be coupled via a LAN to a headend switching device 522 such as an 802.3z Gigabit Ethernet (or “10G”) device. For downstream delivery via the MSO infrastructure (i.e., QAMs), video and audio content is multiplexed at the headend 507 and transmitted to the edge switch device 538 (which may also comprise an 802.3z Gigabit Ethernet device) via the optical ring 537.

[0150] In one implementation, the CMs 512 shown in FIG. 5a each service a premises or venue, such as a conference center or hospitality structure (e.g., hotel), which includes one or more DU nodes for provision of 5G NR services, and may also service WLAN (e.g., 802.11-2016 compliant Wi-Fi) nodes for WLAN access (e.g., within 2.4 GHz ISM band), or even E-UTRAN femtocells, CBRS (Citizens Broadband Radio Service) nodes, or other such devices.

[0151] In parallel with (or in place of) the foregoing delivery mechanisms, the MSO backbone 531 and other network components can be used to deliver packetized content to the “client” gNB devices 504, 506 via non-MSO networks. For example, so-called “OTT” content (whether tightly coupled or otherwise) can be ingested, stored within the MSO's network infrastructure, and delivered to the gNB CU 504 via an interposed service provider network (which may include a public Internet) 511 (e.g., at a local coffee shop, via a DU connected to the coffee shop's service provider via a modem, with the user's IP-enabled end-user device utilizing an Internet browser or MSO/third-party app to stream content according to an HTTP-based approach over the MSO backbone 531 to the third party network to the service provider modem (or optical demodulator) to the DU, and to the user device via the DU NR wireless interface.

[0152] It will further be recognized that user-plane data/traffic may also be routed and delivered apart from the CU. In one implementation (described above), the CU hosts both the RRC (control-plane) and PDCP (user-plane); however, as but one alternate embodiment, a so-called “ dis-aggregated” CU may be utilized, wherein a CU-CP entity (i.e., CU-control plane) hosts only the RRC related functions, and a CU-UP (CU-user plane) which is configured to host only PDCP/SDAP (user-plane) functions. The CU-CP and CU-UP entities can, in one variant, interface data and inter-process communications via an E1 data interface, although other approaches may be used.

[0153] In certain embodiments, each DU 506 is located within and/or services one or more areas within one or more venues or residences (e.g., a building, room, or plaza for commercial, corporate, academic purposes, and/or any other space suitable for wireless access). Each DU is configured to provide wireless network coverage within its coverage or connectivity range for its RAT (e.g., 5G NR). For example, a venue may have a wireless NR modem (DU) installed within the entrance thereof for prospective customers to connect to, including those in the parking lot via inter alia, their NR or LTE-enabled vehicles or personal devices of operators thereof. Notably, different classes of DU 506 may be utilized. In practical terms, some devices may have a working range on the order of hundreds of feet, while other devices may operate out to thousands of feet or more, the propagation and working range dictated by a number of factors, including the presence of RF or other interferers, physical topology of the venue/area, energy detection or sensitivity of the receiver, etc. Similarly, different types of NR-enabled DU 506 can be used depending on these factors, whether alone or with other wireless PHYs such as LTE, WLAN, etc.

[0154] It will also be appreciated that while described primarily with respect to a unitary gNB-CU entity or device 504 as shown in FIG. 5, the present disclosure is in no way limited to such architectures. For example, the techniques described herein may be implemented as part of a distributed or dis-aggregated or distributed CU entity (e.g., one wherein the user plane and control plane functions of the CU are dis-aggregated or distributed across two or more entities such as a CU-C (control) and CU-U (user)), and/or other functional divisions are employed.

[0155] For instance, the individual DU's 506 in FIGS. 5a and 5b communicate data and messaging with the CU 504 via interposed physical communication interfaces and logical interfaces which may include a user plane and control plane, and be embodied in prescribed protocols such as F1AP. In one embodiment, one CU 504 is associated with one or more DU's 506, yet a given DU is only associated with a single CU. Likewise, the single CU 504 can be communicative with a single NG Core such as that operated by an MNO or MSO. Each NG Core may have multiple gNBs associated therewith.

[0156] Two or more gNBs may also be communicative with one another via e.g., an Xn interface, and accordingly can conduct at least CU to CU data transfer and communication. Separate NG Cores may be used for control and user plane (and other) functions of the network. Alternatively, the separate NG Cores may be logically “cross-connected” to the gNBs of one or more other NG Cores, such that one core can utilize/control the infrastructure of another, and vice versa. This may be in “daisy chain” fashion (i.e., one gNB is communicative one other NG Core other than its own, and that NG Core is communicate with yet one additional gNB other than its own, and so forth), or the gNBs and NG Cores may form a “mesh” topology where multiple Cores are in communication with multiple gNBs or multiple different entities (e.g., service providers). Yet other topologies will be recognized by those of ordinary skill given the present disclosure. This cross-connection approach advantageously allows for, inter alia, sharing of infrastructure between two MNOs/MSOs, which is especially useful in e.g., dense deployment environments which may not be able to support multiple sets of RAN infrastructure.

[0157] It is also noted that heterogeneous architectures of eNBs, Home eNBs or femtocells (i.e., E-UTRAN LTE/LTE-A Node B′s or base stations) and gNBs may be utilized consistent with the architectures of FIGS. 4-5a. For instance, a given DU may act (i) solely as a DU (i.e., 5G NR-U PHY node) and operate outside of an E-UTRAN macrocell, or (ii) be physically co-located with an eNB or femtocell and provide NR coverage within a portion of the eNB macrocell coverage area, or (iii) be physically non-colocated with the eNB or femtocell, but still provide NR coverage within the macrocell coverage area.

[0158] Moreover, the DU/CU architectures set forth in co-owned and co-pending U.S. patent application Ser. No 15/945,657 filed Apr. 4, 2018 and entitled “APPARATUS AND METHODS FOR CELL ACTIVATION IN WIRELESS NETWORKS,” incorporated herein by reference in its entirety, may be used consistent with the various aspects of the present disclosure.

[0159] FIG. 5b is a functional block diagram of a second exemplary MSO/MNO network architecture 550, wherein the MNO maintains the majority of 5G NR core infrastructure, such as within the MNO core portion 552, which contains the 5G NR core components outside of the NG-RAN(s), the latter within the MSO service domain 554.

HSS+UDM Apparatus

[0160] FIG. 6 illustrates an exemplary configuration of an enhanced HSS+UDM 430 according to the present disclosure. As shown, the HSS+UDM 401 includes, inter alia, a processor apparatus or subsystem 602, a program memory module 604, mass storage 605 incorporating the parameter (e.g., NMR) database 402 for served UE, HSS (Home Subscriber Server) and UDM (Unified Data Management) logic 606 including management of the foregoing database 402, one or more network interfaces 608.

[0161] In the exemplary embodiment, the processor 602 of the HSS+UDM 401 may include one or more of a digital signal processor, microprocessor, field-programmable gate array, or plurality of processing components mounted on one or more substrates. The processor 602 may also comprise an internal cache memory, and is in communication with a memory subsystem 604, which can comprise, e.g., SRAM, flash and/or SDRAM components. The memory subsystem may implement one or more of DMA type hardware, so as to facilitate data accesses as is well known in the art. The memory subsystem of the exemplary embodiment contains computer-executable instructions which are executable by the processor 602.

[0162] The processing apparatus 602 is configured to execute at least one computer program stored in memory 604 (e.g., a non-transitory computer readable storage medium); in the illustrated embodiment, such programs include HSS+UDM-based NMR DB controller logic 606, such as to serve data from requesting AMF or other entities relating to individual UE or subscriber accounts relating to characterizing data such as NMR data (see discussion of FIGS. 3-3c above), and other logical functions performed by the HSS+UDM as described elsewhere herein. Other embodiments may implement such functionality within dedicated hardware, logic, and/or specialized co-processors (not shown). The HSS+UDM DB controller logic 606 is a firmware or software module that, inter alia, communicates with a corresponding AMF (i.e., for setup for a given UE requesting access via a served NG-RAN with NR-U capability), and/or other upstream or backend entities such as those within the NG Core in some embodiments.

[0163] In some embodiments, the HSS+UDM logic 606 utilizes memory 604 or other storage 605 configured to temporarily hold a number of data relating to the various UE's (including UDM registration data, NMR data, etc.) for the various functions described herein including UE authentication and registration, PCI conflict resolution, etc.).

[0164] The HSS+UDM 401 may further be configured to directly or indirectly communicate with one or more authentication, authorization, and accounting (AAA) servers of the network, such as via the interface 608 shown in FIG. 6 and the MSO backhaul (e.g., where the HSS+UDM is disposed within the MSO infrastructure). The AAA servers, whether locally maintained by the MSO or remotely by e.g., an MNO of the subscriber, are configured to provide services for, e.g., authorization and/or control of network subscribers (including roaming MNO “visitors” to the MSO RAN(s), and/or roaming MSO subscribers visiting an SPLMN of an MNO) for controlling access and enforcing policies, auditing usage, and providing the information necessary to bill for services. As such, the AAA servers themselves may be used to supply NMR data or other similar context-related data necessary to support PCI conflict resolution according to the present disclosure.

[0165] In one exemplary embodiment, the HSS+UDM 401 is maintained by the MSO (see FIG. 5a) and is configured to utilize a non-public IP address within an IMS/Private Management Network “DMZ” of the MSO network. As a brief aside, so-called DMZs (demilitarized zones) within a network are physical or logical sub-networks that separate an internal LAN, WAN, PAN, or other such network from other untrusted networks, usually the Internet. External-facing servers, resources and services are disposed within the DMZ so they are accessible from the Internet, but the rest of the internal MSO infrastructure remains unreachable or partitioned. This provides an additional layer of security to the internal infrastructure, as it restricts the ability of surreptitious entities or processes to directly access internal MSO servers and data via the untrusted network, such as via a MME or AMF “spoof” or MITM attack whereby an attacker might attempt to hijack one or more functional entities to obtain data from the corresponding HSS+UDM.

gNB Apparatus

[0166] FIG. 7 illustrates a block diagram of an exemplary embodiment of a NR-U enabled gNB apparatus, useful for operation in accordance with the present disclosure.

[0167] In one exemplary embodiment as shown, the gNB (which may for instance take any of the forms shown in FIGS. 5a and 5b, including integrated CU 504 and DU 506, distributed CU/DU, etc.) includes, inter alia, a processor apparatus or subsystem 702, a program memory module 704, PCRE logic 706 (here implemented as software or firmware operative to execute on the processor 702), and wireless interfaces 710, 720 for communications with the relevant UE's (e.g., 4G/4.5G E-UTRAN and 5G-NR RAN, respectively).

[0168] The 5G RF interface 720 may be configured to comply with the relevant PHY and CU DU functional “splits” (e.g., Options 1 through 8) according to the relevant 3GPP NR standards which it supports. Returning again to FIG. 7, the antenna(s) 715, 725 of the radios of the gNB(s) may include multiple spatially diverse individual elements in e.g., a MIMO- or MISO-type configuration, such that spatial diversity of the received signals can be utilized. Moreover, a phased array or similar arrangement can be used for spatial resolution within the environment, such as based on time delays associated with signals received by respective elements.

[0169] In one embodiment, the processor apparatus 702 may include one or more of a digital signal processor, microprocessor, field-programmable gate array, or plurality of processing components mounted on one or more substrates. The processor apparatus 702 may also comprise an internal cache memory. The processing subsystem is in communication with a program memory module or subsystem 704, where the latter may include memory which may comprise, e.g., SRAM, flash and/or SDRAM components. The memory module 704 may implement one or more of direct memory access (DMA) type hardware, so as to facilitate data accesses as is well known in the art. The memory module of the exemplary embodiment contains one or more computer-executable instructions that are executable by the processor apparatus 702. A mass storage device (e.g., HDD or SSD, or NAND/NOR flash or the like) is also provided as shown.

[0170] The processor apparatus 702 is configured to execute at least one computer program stored in memory 704 (e.g., the logic of the PCRE including enhanced functions of PCI conflict resolution and operation according to the methods of FIGS. 3-3c herein, in the form of software or firmware that implements the various functions). Other embodiments may implement such functionality within dedicated hardware, logic, and/or specialized co-processors (not shown).

[0171] In some embodiments, the PCRE logic 706 also utilizes memory 704 or other storage 705 configured to temporarily and/or locally hold a number of data relating to the various NMR data and associations for the various UE which it services under the NR-U standard(s). In other embodiments, application program interfaces (APIs) may also reside in the internal cache or other memory 704. Such APIs may include common network protocols or programming languages configured to enable communication between the PCRE and other network entities (e.g., via API “calls” to or from the HSS+UDM 401 or AMF 426).

[0172] It will be recognized that while certain aspects of the disclosure are described in terms of a specific sequence of steps of a method, these descriptions are only illustrative of the broader methods of the disclosure, and may be modified as required by the particular application. Certain steps may be rendered unnecessary or optional under certain circumstances. Additionally, certain steps or functionality may be added to the disclosed embodiments, or the order of performance of two or more steps permuted. All such variations are considered to be encompassed within the disclosure disclosed and claimed herein.

[0173] While the above detailed description has shown, described, and pointed out novel features of the disclosure as applied to various embodiments, it will be understood that various omissions, substitutions, and changes in the form and details of the device or process illustrated may be made by those skilled in the art without departing from the disclosure. This description is in no way meant to be limiting, but rather should be taken as illustrative of the general principles of the disclosure. The scope of the disclosure should be determined with reference to the claims.

[0174] It will be further appreciated that while certain steps and aspects of the various methods and apparatus described herein may be performed by a human being, the disclosed aspects and individual methods and apparatus are generally computerized/computer-implemented. Computerized apparatus and methods are necessary to fully implement these aspects for any number of reasons including, without limitation, commercial viability, practicality, and even feasibility (i.e., certain steps/processes simply cannot be performed by a human being in any viable fashion).

TABLE-US-00009 APPENDIX I MODIFIED NR ASN.1 (TS 38.331)  © Copyright 2018-2019 Charter Communications Operating, LLC. MeasObjectNR information element -- ASN1START -- TAG-MEAS-OBJECT-NR-START MeasObjectNR ::= SEQUENCE {   ssbFrequency  ARFCN-ValueNR  OPTIONAL,  -- Cond SSBorAssociatedSSB   ssbSubcarrierSpacing   SubcarrierSpacing  OPTIONAL,  -- Cond SSBorAssociatedSSB   smtc1  SSB-MTC  OPTIONAL,  -- Cond SSBorAssociatedSSB   smtc2  SSB-MTC2  OPTIONAL,  -- Cond IntraFreqConnected   refFreqCSI-RS  ARFCN-ValueNR    OPTIONAL,   referenceSignalConfig  ReferenceSignalConfig,   absThreshSS-BlocksConsolidation  ThresholdNR    OPTIONAL,  -- Need R   absThreshCSI-RS-Consolidation  ThresholdNR    OPTIONAL,  -- Need R   nrofSS-BlocksToAverage  INTEGER (2..maxNrofSS-BlocksToAverage)    OPTIONAL,  -- Need R   nrofCSI-RS-ResourcesToAverage  INTEGER (2..maxNrofCSI-RS-ResourcesToAverage)    OPTIONAL,  -- Need R   quantityConfigIndex  INTEGER (1..maxNrofQuantityConfig),   offsetMO  Q-OffsetRangeList, measReportLBTScanTime INTEGER (XX..maxMeasRepPCIScanTime) maxMeasRepPCIScanTime INTEGER ::= YY   cellsToRemoveList  PCI-List    OPTIONAL,  -- Need N   cellsToAddModList  CellsToAddModList    OPTIONAL,  -- Need N   blackCellsToRemoveList  PCI-RangeIndexList    OPTIONAL,  -- Need N   blackCellsToAddModList  SEQUENCE (SIZE (1..maxNrofPCI-Ranges)) OF PCI-RangeElement   OPTIONAL, -- Need N   whiteCellsToRemoveList  PCI-RangeIndexList    OPTIONAL,  -- Need N  whiteCellsToAddModList SEQUENCE (SIZE (1..maxNrofPCI-Ranges)) OF PCI-RangeElement  OPTIONAL,  -- Need N   ... ,   [ [   freqBandIndicatorNR-v1530   FreqBandIndicatorNR OPTIONAL,  -- Need R   measCycleSCell-v1530   ENUMERATED {sf160, sf256, sf320, sf512,sf640, sf1024, sf1280}   OPTIONAL  -- Need R   ] ] } ReferenceSignalConfig::= SEQUENCE {   ssb-ConfigMobility  SSB-ConfigMobility    OPTIONAL,  -- Need M   csi-rs-ResourceConfigMobility  SetupRelease {CSI-RS-ResourceConfigMobility }    OPTIONAL  -- Need M } SSB-ConfigMobility::= SEQUENCE {   ssb-ToMeasure   SetupRelease {SSB-ToMeasure }    OPTIONAL,  -- Need M   deriveSSB-IndexFromCell  BOOLEAN,   ss-RSSI-Measurement    SS-RSSI-Measurement OPTIONAL,  -- Need M   ... } Q-OffsetRangeList ::= SEQUENCE {   rsrpOffsetSSB  Q-OffsetRange DEFAULT dB0,   rsrgOffsetSSB  Q-OffsetRange DEFAULT dB0,   sinrOffsetSSB  Q-OffsetRange DEFAULT dB0,   rsrpOffsetCSI-RS  Q-OffsetRange DEFAULT dB0,   rsrqOffsetCSI-RS  Q-OffsetRange DEFAULT dB0,   sinrOffsetCSI-RS  Q-OffsetRange DEFAULT dB0 } ThresholdNR ::= SEQUENCE{   thresholdRSRP  RSRP-Range OPTIONAL,   -- Need R   thresholdRSRQ  RSRQ-Range OPTIONAL,   -- Need R   thresholdSINR  SINR-Range OPTIONAL   -- Need R } CellsToAddModList ::= SEQUENCE (SIZE (1..maxNrofCellMeas)) OF CellsToAddMod CellsToAddMod ::= SEQUENCE {   physCellId  PhysCellId,   cellIndividualOffset  Q-OffsetRangeList }    -- TAG-MEAS-OBJECT-NR-STOP    -- ASN1STOP

TABLE-US-00010 APPENDIX II MODIFIED 5G UE-NR CAPABILITY IE (TS 38.306) ©Copyright 2018-2019 Charter Communications Operating, LLC. UE-NR-Capability information element -- ASN1START -- TAG-UE-NR-CAPABILITY-START UE-NR-Capability ::= SEQUENCE {  accessStratumRelease  AccessStratumRelease,  pdcp-Parameters  PDCP-Parameters,  rlc-Parameters  RLC-Parameters OPTIONAL,  mac-Parameters  MAC-Parameters OPTIONAL,  phy-Parameters  Phy-Parameters,  rf-Parameters  RF-Parameters,  measAndMobParameters  MeasAndMobParameters OPTIONAL,  fdd-Add-UE-NR-Capabilities  UE-NR-CapabilityAddXDD-Mode OPTIONAL,  tdd-Add-UE-NR-Capabilities  UE-NR-CapabilityAddXDD-Mode OPTIONAL,  fr1-Add-UE-NR-Capabilities  UE-NR-CapabilityAddFRX-Mode OPTIONAL,  fr2-Add-UE-NR-Capabilities  UE-NR-CapabilityAddFRX-Mode OPTIONAL,  featureSets  FeatureSets OPTIONAL,  featureSetCombinations  SEQUENCE (SIZE (1..maxFeatureSetCombinations)) OF FeatureSetCombination   OPTIONAL,  lateNonCriticalExtension OCTET STRING OPTIONAL,  nonCriticalExtension UE-NR-Capability-1530 OPTIONAL } UE-NR-Capability-1530 ::=    SEQUENCE {  fdd-Add-UE-NR-Capabilities-1530     UE-NR-CapabilityAddXDD-Mode-1530 OPTIONAL,  tdd-Add-UE-NR-Capabilities-1530     UE-NR-CapabilityAddXDD-Mode-1530 OPTIONAL,  voiceOverMCG-Bearer     ENUMERATED {supported} OPTIONAL,  interRAT-Parameters     InterRAT-Parameters OPTIONAL,  inactiveState     ENUMERATED{supported} OPTIONAL, delayBudgetReporting    ENUMERATED{supported} OPTIONAL, noMobiiltyRequired      ENUMERATED(supported,not supported OPTIONAL,  nonCriticalExtension     SEQUENCE { } OPTIONAL } UE-NR-CapabilityAddXDD-Mode ::=    SEQUENCE {  phy-ParametersXDD-Diff     Phy-ParametersXDD-Diff OPTIONAL,  mac-ParametersXDD-Diff     MAC-ParametersXDD-Diff OPTIONAL,  measAndMobParametersXDD-Diff     MeasAndMobParametersXDD-Diff OPTIONAL } UE-NR-CapabilityAddXDD-Mode-1530 ::=   SEQUENCE {  eutra-ParametersXDD-Diff     EUTRA-ParametersXDD-Diff } UE-NR-CapabilityAddFRX-Mode ::=  SEQUENCE {  phy-ParametersFRX-Diff    Phy-ParametersFRX-Diff OPTIONAL,  measAndMobParametersFRX-Diff    MeasAndMobParametersFRX-Diff OPTIONAL } -- TAG-UE-NR-CAPABILITY-STOP -- ASN1STOP

TABLE-US-00011 APPENDIX III MODIFIED NR INCLUDING PLMN NUMBER LIMIT - ASN.1 (TS 38.331) © Copyright 2018-2019 Charter Communications Operating, LLC. MeasObjectNR information element -- ASN1START -- TAG-MEAS-OBJECT-NR-START MeasObjectNR ::= SEQUENCE {   ssbFrequency  ARFCN-ValueNR OPTIONAL,  -- Cond SSBorAssociatedSSB   ssbSubcarrierSpacing   SubcarrierSpacing OPTIONAL,  -- Cond SSBorAssociatedSSB   smtc1  SSB-MTC OPTIONAL,  -- Cond SSBorAssociatedSSB   smtc2  SSB-MTC2 OPTIONAL,  -- Cond IntraFreqConnected   refFreqCSI-RS  ARFCN-ValueNR OPTIONAL,   referenceSignalConfig  ReferenceSignalConfig,   absThreshSS-BlocksConsolidation  ThresholdNR OPTIONAL,  -- Need R   absThreshCSI-RS-Consolidation  ThresholdNR OPTIONAL,  -- Need R   nrofSS-BlocksToAverage  INTEGER (2..maxNrofSS-BlocksToAverage) OPTIONAL,  -- Need R   nrofCSI-RS-ResourcesToAverage  INTEGER (2..maxNrofCSI-RS-ResourcesToAverage) OPTIONAL,  -- Need R   quantityConfigIndex  INTEGER (1..maxNrofQuantityConfig),   offsetMO  Q-OffsetRangeList, measReportLBTScanTime INTEGER (XX..maxMeasRepPCIScanTime) maxMeasRepPCIScanTime INTEGER ::= YY maxPLMNsPerPCIToReport INTEGER ::= (1..maxNrOfPLMNsPerPCIToReport) OPTIONAL -- maxNrOfPLMNsPerPCIToReport INTEGER ::= 20   cellsToRemoveList  PCI-List OPTIONAL,  -- Need N   cellsToAddModList  CellsToAddModList OPTIONAL,  -- Need N   blackCellsToRemoveList  PCI-RangeIndexList OPTIONAL,  -- Need N   blackCellsToAddModList SEQUENCE (SIZE (1..maxNrofPCI-Ranges)) OF PCI-RangeElement OPTIONAL,  -- Need N   whiteCellsToRemoveList PCI-RangeIndexList  OPTIONAL, -- Need N  whiteCellsToAddModList SEQUENCE (SIZE (1..maxNrofPCI-Ranges)) OF PCI-RangeElement OPTIONAL,  -- Need N   ... ,   [ [   freqBandIndicatorNR-v1530   FreqBandIndicatorNR OPTIONAL,  -- Need R   measCycleSCell-v1530   ENUMERATED {sf160, sf256, sf320, sf512,sf640, sf1024, sf1280} OPTIONAL  -- Need R   ] ] } ReferenceSignalConfig::= SEQUENCE {   ssb-ConfigMobility SSB-ConfigMobility  OPTIONAL,  -- Need M   csi-rs-ResourceConfigMobility SetupRelease { CSI-RS-ResourceConfigMobility }  OPTIONAL  -- Need M } SSB-ConfigMobility::= SEQUENCE {   ssb-ToMeasure  SetupRelease {SSB-ToMeasure }  OPTIONAL,  -- Need M   deriveSSB-IndexFromCell BOOLEAN,   ss-RSSI-Measurement    SS-RSSI-Measurement OPTIONAL,  -- Need M   ... } Q-OffsetRangeLEst ::= SEQUENCE {   rsrpOffsetSSB Q-OffsetRange DEFAULT dB0,   rsrqOffsetSSB Q-OffsetRange DEFAULT dB0,   sinrOffsetSSB Q-OffsetRange DEFAULT dB0,   rsrpOffsetCSI-RS Q-OffsetRange DEFAULT db0,   rsrgOffsetCSI-RS Q-OffsetRange DEFAULT dB0,   sinrOffsetCSI-RS Q-OffsetRange DEFAULT dB0 } ThresholdNR ::= SEQUENCE{  thresholdRSRP RSRP-Range OPTIONAL,  -- Need R  thresholdRSRQ RSRQ-Range OPTIONAL,  -- Need R  thresholdSINR SINR-Range OPTIONAL  -- Need R } CellsToAddModList ::= SEQUENCE (SIZE (1..maxNrofCellMeas)) OF CellsToAddMod CellsToAddMod ::= SEQUENCE {  physCellId PhysCellId,  cellIndividualOffset Q-OffsetRangeList }    -- TAG-MEAS-OBJECT-NR-STOP    -- ASN1STOP -- ASN1START -- TAG-PCI-RANGE-START PCI-Range ::= SEQUENCE {   start   PhysCellId,   range   ENUMERATED {n4, n8, n12, n16, n24, n32, n48, n64, n84, n96, n128, n168, n252, n504,   n1008,spare1} OPTIONAL -- Need S   nrCellId   CellGlobalIdNR OPTIONAL -- PCIs of specific PLMNs for which Measurements Reports are to be disabled } CellGlobalIdNR ::=   SEQUENCE {    plmn-Identity       PLMN-Identity,   cellIdentity         CellIdentity } -- TAG-PCI-RANGE-STOP -- ASN1STOP -  MeasResults IE -- ASN1START -- TAG-MEAS-RESULTS-START MeasResults ::= SEQUENCE {   measId MeasId,   measResultServingMOList MeasResultServMOList,   measResultNeighCells CHOICE {    measResultListNR  MeasResultListNR,    ...,    measResultListEUTRA  MeasResultListEUTRA   } OPTIONAL,   ... } MeasResultServMOList ::= SEQUENCE (SIZE (1..maxNrofServEngCells)) OF MeasResultServMO MeasResultServMO ::= SEQUENCE {   servCellId ServCellIndex,   measResultServingCell MeasResultNR,   measResultBestNeighCell MeasResultNR OPTIONAL,  ... } MeasResultListNR ::= SEQUENCE (SIZE (1..maxCellReport)) OF MeasResultNR MeasResultNR ::= SEQUENCE {   physCellId PhysCellId OPTIONAL,   plmn-Identity PLN-Identity OPTIONAL   measResult SEQUENCE {    cellResults  SEQUENCE{     resultsSSB-Cell   MeasQuantityResults OPTIONAL,     resultsCSI-RS-Cell   MeasQuantityResults OPTIONAL    },    rsIndexResults  SEQUENCE{     resultsSSB-Indexes   ResultsPerSSB-IndexList OPTIONAL,     resultsCSI-RS-Indexes   ResultsPerCSI-RS-IndexList OPTIONAL    } OPTIONAL   },   ...,   [ [   cgi-Info  CGI-Info OPTIONAL   ] ] } MeasResultListEUTRA ::= SEQUENCE (SIZE (1..maxCellReport)) OF MeasResultEUTRA MeasResultEUTRA ::= SEQUENCE {   physCellId PhysCellId,   measResult MeasQuantityResultsEUTRA,   cgi-Info SEQUENCE {    cgi-info-EPC  SEQUENCE {     cgi-info-EPC-legacy   CellAccessRelatedInfo-EUTRA-EPC,     cgi-info-EPC-list   SEQUENCE (SIZE (1..maxPLMN)) OF CellAccessRelatedInfo-EUTRA-EPC OPTIONAL    } OPTIONAL,    cgi-info-5GC   SEQUENCE (SIZE (1..maxPLMN)) OF CellAccessRelatedInfo-EUTRA-5GC OPTIONAL,    freqBandIndicator   FreqBandIndicatorEUTRA,    multiBandInfoList   MultiBandInfoListEUTRA OPTIONAL,    freqBandIndicatorPriority   ENUMERATED {true} OPTIONAL   } OPTIONAL,   ... } MultiBandInfoListEUTRA ::= SEQUENCE (SIZE (1..maxMultiBands)) OF FreqBandIndicatorEUTRA MeasQuantityResults ::= SEQUENCE {  rsrp RSRP-Range OPTIONAL,  rsrq RSRQ-Range OPTIONAL,  sinr SINR-Range OPTIONAL } MeasQuantityResultsEUTRA ::= SEQUENCE {  rsrp RSRP-RangeEUTRA OPTIONAL,  rsrq RSRQ-RangeEUTRA OPTIONAL,  sinr SINR-RangeEUTRA OPTIONAL } ResultsPerSSB-IndexList::= SEQUENCE (SIZE (1..maxNrofIndexesToReport2)) OF ResultsPerSSB-Index ResultsPerSSB-Index ::= SEQUENCE {  ssb-Index SSB-Index,  ssb-Results MeasQuantityResults OPTIONAL } ResultsPerCSI-RS-IndexList::= SEQUENCE (SIZE (1..maxNrofIndexesToReport2)) OF ResultsPerCSI-RS-Index ResultsPerCSI-RS-Index ::= SEQUENCE {  csi-RS-Index CSI-RS-Index,  csi-RS-Results MeasQuantityResults OPTIONAL } -- TAG-MEAS-RESULTS-STOP -- ASN1STOP

TABLE-US-00012 APPENDIX IV MODIFIED NR - ALTERNATE EMBODIMENT- ASN.1 (TS 38.331) © Copyright 2018-2019 Charter Communications Operating, LLC. MeasObjNR IE -- ASN1START -- TAG-MEASOBJECTNR-START MeasObjectNR ::= SEQUENCE {  ssbFrequency  ARFCN-ValueNR OPTIONAL,  -- Cond SSBorAssocEatedSSB  ssbSubcarrEerSpacing  SubcarrierSpacEng OPTIONAL,  -- Cond SSBorAssocEatedSSB  smtc1  SSB-MTC OPTIONAL,  -- Cond SSBorAssocEatedSSB  smtc2  SSB-MTC2 OPTIONAL,  -- Cond IntraFreqConnected  refFreqCSI-RS  ARFCN-ValueNR OPTIONAL,  -- Cond CSI-RS  referenceSignalConfig  ReferenceSignalConfig,  absThreshSS-BlocksConsolidation  ThresholdNR OPTIONAL,  -- Need R  absThreshCSI-RS-Consolidation  ThresholdNR OPTIONAL,  -- Need R  nrofSS-BlocksToAverage  INTEGER (2..maxNrofSS-BlocksToAverage) OPTIONAL,  -- Need R  nrofCSI-RS-ResourcesToAverage  INTEGER (2..maxNrofCSI-RS-ResourcesToAverage) OPTIONAL,  -- Need R  quantityConfigIndex  INTEGER (1..maxNrofQuantityConfig),  offsetMO  Q-OffsetRangeList,  cellsToRemoveList  PCI-List OPTIONAL,  -- Need N  cellsToAddModList  CellsToAddModList OPTIONAL,  -- Need N  blackCellsToRemoveList  PCI-RangeIndexList OPTIONAL,  -- Need N  blackCellsToAddModList  SEQUENCE (SIZE (1..maxNrofPCI-Ranges)) OF PCI-RangeElement OPTIONAL,  -- Need N  whiteCellsToRemoveList  PCI-RangeIndexList OPTIONAL,  -- Need N  whiteCellsToAddModList  SEQUENCE (SIZE (1..maxNrofPCI-Ranges)) OF PCI-RangeElement OPTIONAL,  -- Need N  ... ,  [ [  freqBandIndEcatorNR-v1530  FreqBandIndEcatorNR OPTIONAL,  -- Need R  measCycleSCell-v1530  ENUMERATED {sf160, sf256, sf320, sf512, sf640, sf1024, sf1280} OPTIONAL  -- Need R  ] ]  [ [  measReportLBTScanTime  INTEGER (XX..maxMeasRepPCIScanTime) OPTIONAL,  maxMeasRepPCIScanTime  INTEGER ::= YY OPTIONAL,  maxPLMNsPerPCIToReport  INTEGER ::= (1..maxNrOfPLMNsPerPCIToReport) OPTIONAL,  maxNrOfPLMNsPerPCIToReport  INTEGER ::= 20 OPTIONAL,  blackCellsToAddModList  BlockPCIOfCertainPLMNs OPTIONAL,  blackCellsToRemoveList  BlockPCIOfCertainPLMNs OPTIONAL  ] ] } ReferenceSignalConfig::= SEQUENCE {  ssb-ConfigMobility  SSB-ConfigMobility OPTIONAL,  -- Need M  csi-rs-ResourceConfigMobility  SetupRelease { CSI-RS-ResourceConfigMobility } OPTIONAL  -- Need M } SSB-ConfEgMobility::= SEQUENCE {  ssb-ToMeasure   SetupRelease { SSB-ToMeasure } OPTIONAL,  -- Need M  deriveSSB-IndexFromCell  BOOLEAN,  ss-RSSI-Measurement    SS-RSSI-Measurement OPTIONAL,  -- Need M  ... } Q-OffsetRangeList ::= SEQUENCE {  rsrpOffsetSSB  Q-OffsetRange DEFAULT dB0,  rsrgOffsetSSB  Q-OffsetRange DEFAULT dB0,  sEnrOffsetSSB  Q-OffsetRange DEFAULT dB0,  rsrpOffsetCSI-RS  Q-OffsetRange DEFAULT dB0,  rsrqOffsetCSI-RS  Q-OffsetRange DEFAULT dB0,  sinrOffsetCSI-RS  Q-OffsetRange DEFAULT dB0 } ThresholdNR ::= SEQUENCE {  thresholdRSRP  RSRP-Range OPTIONAL,  -- Need R  thresholdRSRQ  RSRQ-Range OPTIONAL,  -- Need R  thresholdSINR  SINR-Range OPTIONAL  -- Need R } CellsToAddModList ::= SEQUENCE (SIZE (1..maxNrofCellMeas)) OF CellsToAddMod CellsToAddMod ::= SEQUENCE {  physCellId  PhysCellId,  cellIndividualOffset  Q-OffsetRangeList } BlockPCIOfCertainPLMNs::= SEQUENCE }  cellIdentity  CellIdentity OPTIONAL,  plmn-Identity  PLN-Identity OPTIONAL } -- TAG-MEASOBJECTNR-STOP -- ASN1STOP