EP4487618A1 - Intégration de service externe avec des réseaux cellulaires - Google Patents

Intégration de service externe avec des réseaux cellulaires

Info

Publication number
EP4487618A1
EP4487618A1 EP23712992.9A EP23712992A EP4487618A1 EP 4487618 A1 EP4487618 A1 EP 4487618A1 EP 23712992 A EP23712992 A EP 23712992A EP 4487618 A1 EP4487618 A1 EP 4487618A1
Authority
EP
European Patent Office
Prior art keywords
cellular network
core
parameter
cellular
imsi
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP23712992.9A
Other languages
German (de)
English (en)
Inventor
Sougata Saha
Brian Mengwasser
Andrew Trujillo
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Boost Subscriberco LLC
Original Assignee
Dish Wireless LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US18/176,933 external-priority patent/US20230284323A1/en
Application filed by Dish Wireless LLC filed Critical Dish Wireless LLC
Publication of EP4487618A1 publication Critical patent/EP4487618A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/24—Negotiating SLA [Service Level Agreement]; Negotiating QoS [Quality of Service]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices

Definitions

  • 5G cellular networks have considerable flexibility compared to earlier-generation cellular networks.
  • OFD open radio access network
  • cellular network core components that were previously implemented using specialized hardware can now be implemented as specialized software executed on general-purpose computerized hardware.
  • specialized software By using specialized software, considerable flexibility can be present in how the core cellular network operates.
  • an integrated cellular network system may comprise a cellular network.
  • the cellular network may comprise a cellular network core that communicates with a plurality of radio access network (RAN) components of the cellular network.
  • the cellular network may comprise a core application programming interface (API) that allows an external management system, distinct from the cellular network, to modify a plurality of parameters maintained by the cellular network core.
  • the system may comprise the external management system, separate and distinct from the cellular network.
  • the external management system may comprise a user equipment (UE) database.
  • the external management system may comprise a core interface that communicates with the core API via the Internet.
  • the external management system may comprise an engine configured to determine that a UE from the UE database that has its cellular service provided by the cellular network modified.
  • the engine may cause the core interface to transmit a message to the core API instructing the cellular network core to modify a parameter of the plurality of parameters maintained by the cellular network core.
  • the engine may be a quality of service (QoS) engine that may modify a level of QoS provided to the UE by the cellular network using the parameter.
  • the parameter may be a QoS parameter that alters the level of QoS provided by the cellular network to the UE.
  • QoS quality of service
  • the cellular network core may be configured to, in response to the QoS parameter, change which slice the UE is assigned.
  • the engine may be a latency adjustment engine that modifies an amount of latency provided to the UE by the cellular network using the parameter.
  • the parameter may be a latency parameter that alters the amount of latency provided by the cellular network to the UE.
  • the system may further comprise a second RAN, separate and distinct from the RAN of the cellular network.
  • the second RAN may communicate with the cellular network core of the cellular network.
  • the second RAN may be operated by an entity that operates the external management system.
  • the message may comprise an instruction to provide the UE with cellular service via the second RAN.
  • the engine may be an international mobile subscriber identity (IMSI) engine that modifies an IMSI assigned to the UE by the cellular network using the parameter.
  • the parameter may be an IMSI parameter that causes the cellular network to change the IMSI assigned to the UE from a first IMSI to a second IMSI.
  • the IMSI engine modifies the IMSI assigned to the UE by the cellular network using the parameter to change the IMSI assigned to the UE from the second IMSI to the first IMSI.
  • the cellular network may be a 5GNew Radio (NR) cellular network.
  • the cellular network core may be implemented on a public cloudcomputing platform.
  • the UE may communicate with the external management system via the cellular network and via a second wireless network.
  • a method for an external entity to control cellular services may comprise providing, by a cellular network, cellular service to a plurality of user equipment (UE).
  • a cellular network core of the cellular network may communicate with a plurality of radio access network (RAN) components of the cellular network.
  • the cellular network core may use a core application programming interface (API) to communicate with an external management system, distinct from the cellular network.
  • the method may comprise receiving, by the cellular network core, via the core API, a request to modify a parameter for a UE of the plurality of UE.
  • the method may comprise modifying, by the cellular network core, the parameter in response to the request received via the core API.
  • the method may comprise providing, by the cellular network, cellular service to the UE in accordance with the modified parameter.
  • the parameter may be a quality of service (QoS) parameter that alters a level of QoS provided by the cellular network to the UE.
  • the method may further comprise, based on the modified parameter, altering a slice to which the UE is assigned.
  • the parameter may be a latency parameter that alters an amount of latency provided by the cellular network to the UE.
  • the parameter may be an IMSI parameter that causes the cellular network to change the IMSI assigned to the UE from a first IMSI to a second IMSI.
  • the parameter may cause the cellular network to provide the UE with cellular service via a second RAN.
  • the second RAN may be separate and distinct from the RAN of the cellular network.
  • the second RAN may communicate with the cellular network core of the cellular network.
  • the method may further comprise determining, by the external management system, that a service provided to the UE is to be modified.
  • the method may further comprise determining, by the external management system, the parameter to be updated at the cellular network.
  • the method may further comprise transmitting, by the external management system, to the cellular network core via the core API, the parameter along with an indication of the UE.
  • the method may further comprise receiving, by the external management system, feedback from the UE via a wireless network distinct from the cellular network.
  • the external management system may determine that the service provided to the UE may be modified based on the feedback.
  • the cellular network may be a 5G New Radio (NR) cellular network.
  • the cellular network core may be executed on a public cloud computing
  • FIG. 1 illustrates an embodiment of a 5G cellular network.
  • FIG. IB illustrates an embodiment of a 5G core of a 5G cellular network.
  • FIG. 2 illustrates an embodiment of a 5G core implemented using a cloud computing platform.
  • FIG. 3 illustrates an embodiment of a system in which an external management system operated by an external entity can communicate with a cellular network core.
  • FIG. 4 illustrates another embodiment of a system in which an external management system operated by an external entity can communicate with a cellular network core.
  • FIG. 5 illustrates another embodiment of a system in which an external management system operated by an external entity can communicate with a cellular network core.
  • FIG. 6 illustrates an embodiment of a method for an external entity modifying a cellular service provided to a UE via communication with a cellular network core.
  • a cellular network can be used to provide a large number of user equipment (UE) with cellular service.
  • UE user equipment
  • component virtualization rather than using specialized hardware, specialized software executed on general-purpose computing platforms can be used to perform many functions of a cellular network.
  • a cellular network can include a radio access network (RAN) and core.
  • the core may be entirely executed on general-purpose computing components. Such an arrangement provides substantial flexibility, such as allowing the core to be executed on a cloud-computing platform.
  • Components within the core may communicate with each other using application programming interfaces (APIs).
  • APIs application programming interfaces
  • Communication access to components within the core of the cellular network may conventionally be limited to other components of the cellular network, such as RAN components and other core components.
  • access can be granted to modify particular parameters that affect performance and functionality of UE within the core.
  • an external management system that is operated by an entity separate and distinct from the cellular network can be granted access to modify one or more parameters maintained by and within the cellular network core.
  • the external management system can be authorized to modify these one or more parameters for UE that have been associated with the external management system. This arrangement can allow the external management system to provide services to and control functionality of UE that would otherwise be unavailable.
  • Such an external management system may use direct access to the cellular network core to modify the quality of service (QoS), latency, or both experienced by a particular UE.
  • QoS quality of service
  • a QoS level, maximum latency, or both provided to the UE can be adjusted in near real time by the external management system.
  • an entity may operate a separate RAN, but rely on the cellular network’s core rather than maintaining its own core.
  • a factory may have cellular radios, antennas, and other RAN components installed on-site, but use the cellular network’s core for hosting cellular communication with a large number of cellular network-enabled internet of things (loT) devices.
  • the external management system can directly interface with the cellular network core to add or remove UE from having access to the separate RAN and the QoS level, latency, or both provided to such devices.
  • the external management system can control the international mobile subscriber identity (IMSI) assigned to a particular UE.
  • IMSI international mobile subscriber identity
  • a user may desire to make a highly secure call by using a different IMSI than typically used by the UE.
  • the external management system can coordinate the IMSI of the UE being temporarily changed such that the call is not linked to the UE’s normal IMSI.
  • a virtualized open radio access network (0-RAN) because components can be implemented as software in the cloud, except for components that need to receive and transmit RF, the functionality of various components can be shifted among different servers, for which the hardware may be maintained by a separate (public) cloud-service provider, to accommodate where the functionality of such components is needed, as detailed in relation to FIG. 2.
  • UE 110 can represent various types of end-user devices, such as smartphones, cellular modems, cellular-enabled computerized devices, sensor devices, manufacturing equipment, gaming devices, access points (APs), any computerized device capable of communicating via a cellular network, etc.
  • UE can also represent any ty pe of device that has incorporated a 5G interface, such as a 5G modem. Examples include sensor devices, Internet of Things (loT) devices, manufacturing robots; unmanned aerial (or land-based) vehicles, network-connected vehicles, environmental sensors, etc.
  • UE 110 may use RF to communicate with various base stations of cellular network 120. As illustrated, two base stations 115 (BS 115-1, 115-2) are illustrated.
  • Real-world implementations of system 100 can include many (e.g., hundreds, thousands) of base stations, and many RUs, DUs, and CUs.
  • BS 115 can include one or more antennas that allow RUs 125 to communicate wirelessly with UEs 110.
  • RUs 125 can represent an edge of cellular network 120 where data is transitioned to wireless communication.
  • the radio access technology (RAT) used by RU 125 may be 5GNew Radio (NR), or some other RAT, such as 4G Long Term Evolution (LTE).
  • the remainder of cellular network 120 may be based on an exclusive 5G architecture, a hybrid 4G/5G architecture, a 4G architecture, or some other cellular network architecture.
  • Base station equipment 121 may include an RU (e.g., RU 125-1) and a DU (e.g., DU 127-1) located on site at the base station.
  • the DU may be physically remote from the RU.
  • multiple DUs may be housed at a central location and connected to geographically distant (e.g., within a couple kilometers) RUs.
  • One or more RUs may communicate with DU 127-1.
  • RUs such as RU 125-1
  • DU 127-1 may communicate with CU 129.
  • RUs, DUs, and CUs create a gNodeB, which serves as the radio access network (RAN) of cellular network 120.
  • RAN radio access network
  • CU 129 can communicate with core 139.
  • the specific architecture of cellular network 120 can vary' by embodiment.
  • Edge cloud server systems outside of cellular network 120 may communicate, either directly, via the Internet, or via some other network, with components of cellular network 120.
  • DU 127-1 may be able to communicate with an edge cloud server system without routing data through CU 129 or core 139.
  • Other DUs may or may not have this capability .
  • Network resource management components 150 can include: Network Repository Function (NRF) 152 and Network Slice Selection Function (NSSF) 154.
  • NRF 152 can allow 5G network functions (NFs) to register and discover each other via a standards-based application programming interface (API).
  • NSSF 154 can be used by AMF 182 to assist with the selection of a network slice that will serve a particular UE
  • Policy management components 160 can include: Charging Function (CHF) 162 and Policy Control Function (PCF) 164.
  • CHF 162 allows charging services to be offered to authorized network functions. Converged online and offline charging can be supported.
  • PCF 164 allows for policy control functions and the related 5G signaling interfaces to be supported.
  • Subscriber management components 170 can include: Unified Data Management (UDM) 172 and Authentication Server Function (AUSF) 174.
  • UDM 172 can allow for generation of authentication vectors, user identification handling, NF registration management, and retrieval of UE individual subscription data for slice selection.
  • AUSF 174 performs authentication with UE.
  • Packet control components 180 can include: Access and Mobility Management Function (AMF) 182 and Session Management Function (SMF) 184.
  • AMF 182 can receive connection- and session-related information from UE and is responsible for handling connection and mobility management tasks.
  • SMF 184 is responsible for interacting with the decoupled data plane, creating updating and removing Protocol Data Unit (PDU) sessions, and managing session context with the User Plane Function (UPF).
  • PDU Protocol Data Unit
  • UPF User Plane Function
  • User plane function (UPF) 190 can be responsible for packet routing and forwarding, packet inspection, QoS handling, and external PDU sessions for interconnecting with a DataNetwork (DN) 195 (e.g., the Internet) or various access networks 197.
  • Access networks 197 can include the RAN of cellular network 120 of FIG. 1A. As detailed in relation to FIG. 4, a separate external RAN network may additionally or alternatively be used.
  • FIGS. 1 A and IB illustrate various components of cellular network 120
  • RU 125 may include specialized radio access componentry to enable wireless communication with UE 110
  • other components of cellular network 120 may be implemented using either specialized hardware, specialized firmware, and/or specialized software executed on a general-purpose server system.
  • specialized software on general- purpose hardware may be used to perform the functions of components such as DU 127, CU 129, and core 139. Functionality of such components can be co-located or located at disparate physical server systems. For example, certain components of core 139 may be co-located with components of CU 129.
  • DUs 127, CU 129, core 139, and/or orchestrator 138 can be implemented virtually as software being executed by general-purpose computing equipment, such as in a data center. Therefore, depending on needs, the functionality of a DU, CU, and/or 5G core may be implemented locally to each other and/or specific functions of any given component can be performed by physically separated server systems (e.g., at different server farms). For example, some functions of a CU may be located at a same server facility as where the DU is executed, while other functions are executed at a separate server system.
  • cloud-based cellular network components 128 include CU 129, core 139, and orchestrator 138.
  • DUs 127 may be partially or fully added to cloud-based cellular network components 128.
  • cloud-based cellular network components 128 may be executed as specialized software executed by underlying general-purpose computer servers.
  • Cloud-based cellular network components 128 may be executed on a public third-party cloud-based computing platform or a cloud-based computing platform operated by the same entity that operates the RAN.
  • a cloud-based computing platform may have the ability to devote additional hardware resources to cloud-based cellular network components 128 or implement additional instances of such components when requested.
  • a “public” cloud-based computing platform refers to a platform where various unrelated entities can each establish an account and separately utilize the cloud computing resources, the cloud computing platform managing segregation and privacy of each entity’s data.
  • Kubemetes can be used to create and destroy the logical DU, CU, or 5G core units and subunits as needed for the cellular network 120 to function properly.
  • Kubemetes allows for container deployment, scaling, and management. As an example, if cellular traffic increases substantially in a region, an additional logical DU or components of a DU may be deployed in a data center near where the traffic is occurring without any new hardware being deployed. (Rather, processing and storage capabilities of the data center would be devoted to the needed functions.) When the need for the logical DU or subcomponents of the DU no longer exists, Kubemetes can allow for removal of the logical DU. Kubemetes can also be used to control the flow of data (e.g., messages) and inject a flow of data to various components. This arrangement can allow for the modification of nominal behavior of various layers.
  • data e.g., messages
  • Orchestrator 138 can represent various software processes executed by underlying computer hardware. Orchestrator 138 can monitor cellular network 120 and determine the amount and location at which cellular network functions should be deployed to meet or attempt to meet service level agreements (SLAs) across slices of the cellular network.
  • SLAs service level agreements
  • Orchestrator 138 can allow for the instantiation of new cloud-based components of cellular network 120, including components detailed in relation to FIGS. 1A, IB, and 2.
  • orchestrator 138 can perform a pipeline of calling the DU code from a software repository incorporated as part of, or separate from, cellular network 120; pulling corresponding configuration files (e.g., helm charts); creating Kubemetes nodes/pods; loading DU containers; configuring the DU; and activating other support functions (e.g., Prometheus, instances/connections to test tools).
  • a network slice functions as a virtual network operating on cellular network 120.
  • Cellular network 120 is shared with some number of other network slices, such as hundreds or thousands of network slices. Communication bandwidth and computing resources of the underlying physical network can be reserved for individual network slices, thus allowing the individual network slices to reliably meet particular SLA levels and parameters.
  • the SLA attributes for UE on the network slice can be varied on different slices
  • a network slice can be configured to provide sufficient resources for a particular application to be properly executed and delivered (e.g., gaming services, video services, voice services, location services, sensor reporting services, data services, etc.). However, resources are not infinite, so allocation of an excess of resources to a particular UE group and/or application may be desired to be avoided.
  • a cost may be attached to cellular slices: the greater the amount of resources dedicated, the greater the cost to the user; thus optimization between performance and cost is desirable.
  • Particular network slices may only be reserved in particular geographic regions. For instance, a first set of network slices may be present at RU 125-1 and DU 127-1; a second set of network slices, which may only partially overlap or may be wholly different from the first set, may be reserved at RU 125-2 and DU 127-2.
  • particular cellular network slices may include some number of defined layers. Each layer within a network slice may be used to define QoS parameters and other network configurations for particular types of data. For instance, high-priority data sent by a UE may be mapped to a layer having relatively higher QoS parameters and network configurations than lower-priority data sent by the UE that is mapped to a second layer having relatively less stringent QoS parameters and different network configurations.
  • Components such as DUs 127, CU 129, orchestrator 138, and core 139 may include various software components that are required to communicate with each other, handle large volumes of data traffic, and are able to properly respond to changes in the network. In order to ensure not only the functionality and interoperability of such components, but also the ability to respond to changing network conditions and the ability to meet or perform above vendor specifications, significant testing must be performed.
  • FIG. 2 illustrates an embodiment of a cellular network core network topology 200 as implemented on a public cloud-computing platform.
  • Cellular network core network topology 200 can represent how logical cellular network groups are distributed across cloud computing infrastructure of cloud computing platform 201.
  • Cloud computing platform 201 can be logically and physically divided up into various different cloud computing regions 210.
  • Each of cloud computing regions 210 can be isolated from other cloud computing regions to help provide fault tolerance, fail-over, load-balancing, and/or stability and each of cloud computing regions 210 can be composed of multiple availability zones, each of which can be a separate data center located in general proximity to each other (e.g., within 100 miles). Further, each of cloud computing regions 210 may provide superior service to a particular geographic region based on physical proximity.
  • cloud computing region 210-1 may have its datacenters and hardware located in the northeast of the United States while cloud computing region 210-2 may have its datacenters and hardware located in California.
  • cloud computing region 210-1 may have its datacenters and hardware located in the northeast of the United States while cloud computing region 210-2 may have its datacenters and hardware located in California.
  • the details of the cellular network as executed in only cloud computing region 210-1 are illustrated. Similar components may be executed in other cloud computing regions of cloud computing regions 210 (210-2, 210-3, 210-n).
  • cloud computing platform 201 may be a private cloud computing platform.
  • a private cloud computing platform may be maintained by a single entity, such as the entity that operates the hybrid cellular network. Such a private cloud computing platform may be only used for the hybrid cellular network and/or for other uses by the entity that operates the hybrid cellular network (e.g., streaming content delivery).
  • Each of cloud computing regions 210 may include multiple availability zones 215.
  • Each of availability zones 215 may be a discrete data center or group of data centers that allow for redundancy that allows for fail-over protection from other availability zones within the same cloud computing region. For example, if a particular data center of an availability zone experiences an outage, another data center of the availability zone or separate availability zone within the same cloud computing region can continue functioning and providing service.
  • a logical cellular network component such as a national data center, can be created in one or across multiple availability zones 215.
  • cloud computing region 210-1 may include the ability to use a different type of data center or group of data centers, which can be referred to as local zones 220.
  • a client such as a provider of the hybrid cloud cellular network can select from more options of the computing resources that can be reserved at an availability zone compared to a local zone.
  • a local zone may provide computing resources nearby geographic locations where an availability zone is not available. Therefore, to provide low latency, certain network components, such as regional data centers, can be implemented at local zones 220 rather than availability zones 215.
  • a geographic region can have both a local zone and an availability zone.
  • NDC 230 can be understood as having its functionality existing in cloud computing region 210-1 across multiple availability zones 215.
  • various network functions such as NFs 232, are executed.
  • NFs 232 are executed.
  • each NF whether at NDC 230 or elsewhere located, can be comprised of multiple sub-components, referred to as pods (e.g., pod 211) that are each executed as a separate process by the cloud computing environment.
  • pods e.g., pod 211
  • the illustrated numbers of pods are merely an example; fewer or greater numbers of pods may be part of the respective 5G core functions.
  • a cellular network core can include many more network functions. By distributing NFs 232 across availability zones, load-balancing, redundancy, and fail-over can be achieved.
  • multiple regional data centers 240 can be logically present. Each of regional data centers 240 may execute 5G core functions for a different geographic region or group of RAN components.
  • 5G core components that can be executed within an RDC, such as RDC 240-1 may be: UPFs 250, SMFs 260, and AMFs 270. While instances of UPFs 250 and SMFs 260 may be executed in local zones 220, SMFs 260 may be executed across multiple local zones 220 for redundancy, processing load-balancing, and fail-over.
  • FIG. 3 illustrates an embodiment of an integrated cellular network system 300 (“system 300”) in which an external entity operating that is external management system 330 (“EMS 330”) communicates with a cellular network to provide add-on services related to adjustment of QoS and/or latency parameters.
  • system 300 an integrated cellular network system 300
  • EMS 330 external management system 330
  • cellular network 120 has core API 320 exposed to authorized external systems, such as EMS 330, that allows for external access to modify various parameters maintained at core 139.
  • EMS 330 can be permitted to alter particular parameters corresponding to UE that have been associated with EMS 330.
  • EMS 330 may be operated by an entity that operates a manufacturing facility.
  • EMS 330 may be granted access to modify particular parameters maintained for the UE at core 139 via core API 320 that control the QoS and latency provided to the individual UE (e.g., sensor devices, manufacturing robots) operated by the entity at the manufacturing facility.
  • EMS 330 can include various components, such as: QoS engine 332, latency engine 334, UE database 338 (“UE DB 338”) and core interface 336.
  • Core interface 336 can communicate via requests and responses with core API 320 via a network, such as Internet 301.
  • a request can be transmitted by EMS 330 via core interface 336 that requests that a particular parameter maintained by core 139 be modified.
  • EMS 330 can transmit requests for an adjustment related to QoS, latency, or both.
  • EMS 330 may be implemented using one or more computer systems.
  • EMS 330 may include one or more special-purpose or general-purpose processors.
  • Such special-purpose processors may include processors that are specifically designed to perform the functions of the components detailed herein.
  • Such special-purpose processors may be ASICs or FPGAs which are general-purpose components that are physically and electrically configured to perform the functions detailed herein.
  • Such general-purpose processors may execute specialpurpose software that is stored using one or more non-transitory processor-readable mediums, such as random access memory (RAM), flash memory, a hard disk drive (HDD), or a solid state drive (SSD).
  • RAM random access memory
  • HDD hard disk drive
  • SSD solid state drive
  • the functions illustrated for EMS 330 can be implemented as software components executed on underlying hardware. Further, the functions of the components of EMS 330 can be implemented using a cloud-computing platform, which is operated by a separate cloud-service provider that executes code and provides storage for clients.
  • an operator of a UE desires aspects of the UE and cellular network functionality to be controlled via EMS 330
  • the operator of the UE may grant permission for EMS 330 to control particular aspects of how the UE and cellular network 120 function together.
  • EMS 330 may then access information and control at least some aspects of how the UE functions on cellular network 120.
  • EMS 330 can be operated directly by an entity that desires more control over its UE operating on cellular network 120.
  • a client which may operate EMS 330 or may have permission to use EMS 330, can submit a request via client interface 331.
  • the request may be provided by a UE that determines for a service it is to perform that either a higher QoS is needed or a lower QoS is sufficient.
  • QoS engine 332 may receive the request via client interface 331 and evaluate the request to determine whether the QoS provided by cellular network 120 to a particular UE or group of UE should be adjusted to either increase or decrease the QoS. For instance, in some embodiments, QoS engine 332 may receive an indication of an application or function that is about to be performed by the UE.
  • QoS engine 332 may evaluate the currently provided QoS of cellular network 120 to determine if and how the QoS provided should be adjusted. Alternatively, QoS engine 332 may simply receive the instruction from client interface 331 and enact the request, if permitted. QoS engine 332 may be able to send a request via core interface 336 and core API 320 to retrieve a parameter that indicates a QoS level currently being provided by cellular network 120 to a particular (or group of) UE.
  • a particular parameter maintained by core 139 can define a QoS provided to a UE.
  • the parameter may be indicative of a QoS level provided to the UE.
  • the parameter may have a value between 1 and 5 to denote a minimum desired QoS level.
  • For each QoS level one or more of the following may be defined: maximum packet loss, bit rate (uplink and/or downlink), throughput (uplink and/or downlink), transmission delay, network availability, latency, and jitter. Therefore, by transitioning a UE from a QoS level of 1 to a QoS level of 2, some number of these parameters may be improved.
  • a normal QoS level for a customer of cellular network 120 may be 2 (with 5 being the highest, 1 being the lowest).
  • a QoS level of 1 may be desired when the data being obtained from or sent to a UE is not time sensitive.
  • a UE may typically function as a sensor that needs to occasionally report data.
  • a low QoS e.g., QoS level of 1
  • QoS level of 3 may be entirely sufficient for data reporting that is not time sensitive.
  • a relatively higher QoS e.g., QoS level of 3
  • QoS e.g., QoS level of 3
  • QoS engine 332 based on the request received via client interface, the currently provided QoS level for the UE, and possibly data retrieved from UE DB 338, can transmit a request via core interface 336 to core API 320 requesting that a QoS parameter for the UE be modified. This request can be transmitted directly to core 139 of cellular network 120 via core API 320. In response to receiving the updated QoS level, core 139 can adjust how the UE (or group of UEs) are provided service.
  • cellular network 120 may reassign the UE (or group of UE) to a different slice of cellular network 120.
  • This different slice may be configured to satisfy the minimum parameters of the requested QoS level and may also be operating in the geographic region where the UE is located.
  • a UE itself may request an adjustment in QoS level via EMS 330.
  • a UE such as UE 110-3, may determine that it is not receiving sufficient QoS from cellular network 120 in order to perform a particular task.
  • UE 110-3 can transmit a message to client interface 331 indicating that a QoS change is needed.
  • This request can be transmitted via cellular network 120 or via some other network connection via Internet 301, such as a WiFi connection to an Internet Service Provider (ISP).
  • ISP Internet Service Provider
  • latency may be managed separately from QoS levels.
  • Latency engine 334 may function similarly to QoS engine 332: a request may be provided by a UE that determines for a service it is to perform that either a lower latency is needed or that a higher latency would be sufficient. Latency engine 334 may receive the request via client interface 331 and evaluate the request to determine whether the latency provided by cellular network 120 to a particular UE or group of UE should be adjusted to either increase or decrease a maximum permitted latency. For instance, in some embodiments, latency engine 334 may receive an indication of an application or function that is about to be performed by the UE. Latency engine 334 may evaluate the latency currently provided by cellular network 120 to determine if and how the latency should be adjusted.
  • latency engine 334 may simply receive the instruction from client interface 331 and enact the request, if permitted.
  • Latency engine 334 may be able to send a request via core interface 336 and core API 320 to retrieve a parameter that indicates a latency or latency level currently being provided by cellular network 120 to a particular (or group of) UE.
  • the slice the UE is assigned to may be changed.
  • different instantiations of core components which were identified as having higher or lower average latency may be used for the UE.
  • client interface 331 may also receive a request from some other source.
  • a computer system of the entity that operates the UE may desire to adjust the QoE, latency, or both for various reasons.
  • a particular UE may be known to be important (or unimportant) for an upcoming action or project, so the QoE, latency, or both may be preemptively adjusted.
  • the QoE, latency, or both may be adjusted based on a particular UE having been reassigned in function (e.g., from video capture to periodic image still capture).
  • UE DB 338 may store data about each UE for which EMS 330 can alter the QoS, latency, or both.
  • UE DB 338 may be used to store information about the current QoS level and/or latency for each UE at cellular network 120.
  • UE DB 338 may also be used to store information about the function each UE is currently being used for and conditions particular to the UE that are to be used to trigger a QoS and/or latency adjustment.
  • UE DB 338 may store an indication that, for a particular UE, the UE is not permitted to be given a QoS level above some predetermined maximum level.
  • FIG. 4 illustrates another embodiment of an integrated cellular network system 400 (“system 400”) in which an external management system operated by an external entity can communicate with a cellular network core.
  • access manager 420 is present as a component in EMS 330. (In some embodiments, access manager 420 is present in addition to QoS engine 332, latency engine 334, or both.)
  • External RAN 410 can be operated by an entity distinct from the cellular network provider.
  • the operator of a group of UE may operate external RAN 410.
  • External RAN 410 can include: RUs 414; DUs 412; and CU 416.
  • the specific number of DUs, RU, and CUs, included in external RAN 410 can vary by the size of external RAN 410.
  • a single RU and DU may be present in external RAN 410, such as to service a single relatively small site (e g., within one warehouse).
  • external RAN 410 may have many RUs 414 and DUs 412 to service many different geographic locations (e.g., warehouses scattered across the country).
  • CU 416 is present.
  • a CU can manage radio resource control (RRC), the service data adaptation protocol (SDAP), and PDCP protocol layers, and can be responsible for non-real-time RRC, and the packet data convergence protocol (PDCP) stack functions.
  • RRC radio resource control
  • SDAP service data adaptation protocol
  • PDCP packet data convergence protocol
  • the CU may be implemented as part of external RAN 410 or as part of core 139 and executed on a cloud computing system, and thus separate from external RAN 410. For example, if CU 416 is not present in external RAN 410, DUs 412 may logically communicate with CU 129 and core 139.
  • core 139 serves to provide external RAN 410 with core functionality.
  • a high-speed connection e.g., dedicated bandwidth on a private fiber network
  • Core 139 provides all of the core functionality needed by external RAN 410. Specifically which UE and the services, QoE level, and latency provided to UE 418 are managed by EMS 330.
  • EMS 330 via communication with core 139 via core API 320, can adjust parameter and register/ deregister UE for access to external RAN 410.
  • This arrangement allows an entity to maintain a simplified RAN for which only the entity’s UE are permitted access, while still allowing the entity significant control via interfacing with core 139 to control parameters and registration of UE.
  • the specific services e.g., text messaging, calls, Internet access
  • UE 418 can be controlled.
  • a request can be received from a UE of UE 418 or from some other system of the client that operates external RAN 410.
  • EMS 330 may be operated by the same entity operating external RAN 410 or by some other external entity.
  • the request can dictate: a UE (or group of UE) to be added or removed from external RAN access; services to be provided or blocked at specific UE (or a group of UE); a QoS level to provide to a specific UE (or group of UE); a maximum latency to provide to a specific UE (or group of UE).
  • FIG. 5 illustrates another embodiment of an integrated cellular network system 500 (“sy stem 500”) in which an external management system operated by an external entity can communicate with a cellular network core.
  • EMS 330 includes IMSI engine 510, which is used to alter the IMSI assigned to a UE.
  • System 500 can be incorporated with systems 300 and 400, thus allowing IMSI modification to be performed in combination with control of QoS level, maximum latency, use of an external RAN, or some combination thereof.
  • An IMSI is a unique number assigned to a device on a cellular network. Typically, it is a fifteen digit number that is stored by and sent by the UE to the cellular network.
  • the IMSI can be used to store information by the cellular network about the UE.
  • An IMSI has security implications. Typically, an IMSI is sent over the cellular network as infrequently as possible to reduce the opportunity for the IMSI to be acquired by a nefarious actor. If acquired or stolen, an IMSI can be used to eavesdrop on communications involving the UE to which the IMSI is assigned and/or track the location of the UE.
  • the IMSI may be altered by EMS 330.
  • IMSI engine 510 of EMS 330 can access core 139 of the cellular network to change the IMSI for a UE.
  • a user may desire to make a highly secure phone call. Before doing so, the user may send a request from his UE to EMS 330 requesting that the IMSI of his UE be altered for the next 2 hours.
  • IMSI engine 510 after retrieving details of the UE from UE DB 338, may send a request to core 139 via core API 320, causing the IMSI of the UE to be altered.
  • the phone call can be performed by the UE with a reduced chance of eavesdropping or tracking due to a previously stolen IMSI of the UE.
  • the IMSI of the UE may be switched back to the original IMSI of the UE.
  • such an arrangement can help prevent the location of the UE being tracked while the temporarily assigned IMSI is being used.
  • a user may request that the IMSI of his UE be altered periodically, such as once per day.
  • IMSI engine 510 based on data stored in association with the UE in UE DB 338 (e.g., the frequency at which the IMSI should be updated for the UE), can cause the cellular network to change the IMSI at core 139 by sending a request via core API 320.
  • FIG. 6 illustrates an embodiment of a method 600 for an external entity modifying cellular service provider to a UE via communication with a cellular network core.
  • Method 600 can be performed using system 300, system 400, system 500, or some combination thereof.
  • cellular service is provided by a cellular network to various UE. These UE have been associated with or mapped to an external provider that either operates or has permission to use an external management system, such as EMS 330.
  • one or more parameters that are permited to be modified by the EMS in the cellular network’s core are determined and values for such parameters are determined. As previously detailed, these parameters can relate to: QoS level, maximum latency, IMSI assignment, available services, and/or external RAN access. (UE being granted access or removed from access to the external RAN may not have been provided cellular services by the cellular network at block 610.)
  • a request with the one or more parameters is transmitted to the cellular network core along with an indication of the UE (or group of UE) for which the parameter is to be modified.
  • an indication of the UE (or group of UE) for which the parameter is to be modified can be authentication information used by the cellular network to authenticate that the EMS has permission to access the parameters at the core and has permission to adjust parameters for the requested UE
  • the cellular network core updates the one or more parameters indicated in the request of block 640 and updates how services and functionality are provided to the UE based on the adjusted parameter.
  • cellular senices are available to the UE in accordance with the one or more modified parameters. Method 600 can then be repeated as often as needed as determined by the EMS.
  • the embodiments may be described as a process which is depicted as a flow diagram or block diagram. Although each may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be rearranged. A process may have additional steps not included in the figure.

Landscapes

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

Abstract

Sont détaillées ici des configurations pour modifier la fonctionnalité d'un équipement utilisateur (UE) d'un réseau cellulaire et le service fourni audit UE par le biais d'une intégration avec un système de gestion externe. Une interface de programmation d'applications (API) centrale peut autoriser le système de gestion externe, distinct du réseau cellulaire, à modifier un ou plusieurs paramètres gérés par le cœur de réseau cellulaire.
EP23712992.9A 2022-03-02 2023-03-02 Intégration de service externe avec des réseaux cellulaires Pending EP4487618A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US202263315823P 2022-03-02 2022-03-02
US18/176,933 US20230284323A1 (en) 2022-03-02 2023-03-01 External service integration with cellular networks
PCT/US2023/014325 WO2023167965A1 (fr) 2022-03-02 2023-03-02 Intégration de service externe avec des réseaux cellulaires

Publications (1)

Publication Number Publication Date
EP4487618A1 true EP4487618A1 (fr) 2025-01-08

Family

ID=85727026

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23712992.9A Pending EP4487618A1 (fr) 2022-03-02 2023-03-02 Intégration de service externe avec des réseaux cellulaires

Country Status (2)

Country Link
EP (1) EP4487618A1 (fr)
WO (1) WO2023167965A1 (fr)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3556131A4 (fr) * 2016-12-19 2020-07-15 Bandwidthx Inc. Délestage optimisé de dispositifs sans fil vers des réseaux sans fil alternatifs
US10673751B2 (en) * 2017-04-27 2020-06-02 At&T Intellectual Property I, L.P. Method and apparatus for enhancing services in a software defined network
US11700628B2 (en) * 2019-03-11 2023-07-11 Intel Corporation Multi-slice support for MEC-enabled 5G deployments
US11252654B2 (en) * 2020-06-19 2022-02-15 Verizon Patent And Licensing Inc. Systems and methods for user-specific slice configuration for an application

Also Published As

Publication number Publication date
WO2023167965A1 (fr) 2023-09-07

Similar Documents

Publication Publication Date Title
US20230284323A1 (en) External service integration with cellular networks
US11445515B2 (en) Network slice selection based on requested service
US10993177B2 (en) Network slice instance creation
US20230103816A1 (en) Hybrid Cloud Cellular Network Routing
US12113674B2 (en) Cellular network cloud application controlled slice management
US20250274850A1 (en) Intelligent anchor point movement
WO2023167964A1 (fr) Intégration d'environnements de test physique à un noyau cellulaire natif en nuage
WO2023059776A1 (fr) Routage de réseau cellulaire en nuage hybride
US20240022948A1 (en) On demand cell-site information collection in a cloud 5g environment
US12563422B2 (en) Intelligent synthetic data injection
EP4487618A1 (fr) Intégration de service externe avec des réseaux cellulaires
US12526364B2 (en) Systems and methods for DNN-based data intercepts
US12192069B1 (en) Multi-layered charging system
US20260052137A1 (en) Network edge protection using locality information
US20250203366A1 (en) Systems and Methods Auto-Discover Instances of Compute Instances and Network Components Instantiated in the 5G Cloud
US20260081825A1 (en) High efficiency and on demand computational environments for 5g network functions
US20250201102A1 (en) Method and system for determining active events in a 5g network
US20260122536A1 (en) Dynamic assignment of radio units (rus) to distributed units (dus) and dus to centralized units (cus) using assignment manager
US20250351010A1 (en) Eps (4g) fallback
US20260082402A1 (en) Systems and methods to dynamically reconfigure network resources within telecommunication networks
US20250126488A1 (en) Site integration management system
US20260075028A1 (en) Automatic detection and failover of multimedia message service center (mmsc) servers from user plane function voice (upfv) in public cloud services
US20260059354A1 (en) Notification control in cloud-native telecommunications networks
US20260012855A1 (en) Dynamic user plane function (upf) scaling
WO2025230816A1 (fr) Mise à l'échelle dynamique de fonction de gestion d'accès et de mobilité (amf)

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

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

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

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

Free format text: ORIGINAL CODE: 0009012

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240905

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: BOOST SUBSCRIBERCO L.L.C.