WO2021004644A1 - Methods and apparatus for providing context information to a network - Google Patents

Methods and apparatus for providing context information to a network Download PDF

Info

Publication number
WO2021004644A1
WO2021004644A1 PCT/EP2019/072532 EP2019072532W WO2021004644A1 WO 2021004644 A1 WO2021004644 A1 WO 2021004644A1 EP 2019072532 W EP2019072532 W EP 2019072532W WO 2021004644 A1 WO2021004644 A1 WO 2021004644A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
network
nef
information
type
Prior art date
Application number
PCT/EP2019/072532
Other languages
French (fr)
Inventor
Rodrigo Alvarez Dominguez
Alfonso De Jesus Perez Martinez
Miguel Angel PUENTE PESTAÑA
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Publication of WO2021004644A1 publication Critical patent/WO2021004644A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/085Retrieval of network configuration; Tracking network configuration history

Definitions

  • Embodiments described herein relate to methods and apparatuses for providing context information relating to an event to a network.
  • the network may adjust to compensate for an event that may have a detrimental effect on the network.
  • Figure 1 illustrates a 5G network architecture with point to point representation.
  • Network Functions correspond to the Core Network Control Plane and they may use Service Based Architecture (SBA) interfaces to communicate with each other.
  • SBA Service Based Architecture
  • the Packet Flow Description Function (PFDF) in 5G has been included inside the Network Exposure Function (NEF) to reduce the number of individual network functions in 5G.
  • the PFDF handles the Packet Flow Descriptions (PFDs) associated with application identifier(s) and transfers them to the Session Management Function (SMF) via (NG) Gw interface.
  • SMF Session Management Function
  • the SMF may then sends these PFDs towards the User Plane Function (UPF) through the N4 PFD Management procedure to enable the UPF to perform accurate application detection when the PFDs are managed by a 3rd party service provider.
  • UPF User Plane Function
  • the T8 interface (which may be defined as in Rel 15 29.122) is between the SCS/AS (Service Capability Server/Application Server) and the NEF in the case of 5G networks, or the SCEF (Service Capability Exposure Function) in the case of 4G networks. It specifies RESTful Application Program Interfaces (APIs) that allow the SCS/AS to access the services and capabilities provided by the 3GPP network entities and securely exposed by the SCEF/NEF.
  • One of those APIs is a monitoring event API (as described in subclause 4.4.6.1 in 23.682) where the SCS/AS can subscribe to some monitoring events like UE loss of connectivity, UE location reporting, UE roaming status, communication failure, change of I MEI-I MSI association.
  • the Policy and Charging Rules Function is a functional element that performs policy control decision and flow-based charging control.
  • the PCF may provide network control regarding the service data flow detection.
  • the User Plane Function encompasses service data flow detection, policy enforcement and flow-based charging functionalities, an anchor point for lntra-/lnter- RAT mobility (when applicable), an external IP point of interconnect, packet routing & forwarding, Quality of Service (QoS) handling for the user plane, packet inspection and Policy and Charging Control (PCC) rule enforcement, lawful intercept (User Plane (UP) collection), roaming interface (UP), traffic counting and reporting.
  • QoS Quality of Service
  • PCC Policy and Charging Control
  • section 6.1 1 defines the following requirement related to the usage of external or contextual information for network optimization purposes:
  • the 5G system shall support network resource utilization efficiently and network optimization based on system information.
  • the information gathered by sensors, the utilized access technologies, the application context, and the application traffic characteristics can provide useful information to the applications installed in the UE and can also help the 5G system utilize resources in an efficient and optimized way.”
  • Contextual network is a term that refers to the usage of contextual information for network control purposes. It comes from the established term “contextual advertising”, which refers to the use of contextual information (e.g. location) to show relevant advertisements to the users.
  • contextual information that may be leveraged in 5G (and the source of such information) are:
  • the organizations in charge of, or who may be aware of the occurrence of these events may then contact the mobile network operators to alert them as to the occurrence of the event.
  • the mobile network operators may then adapt the mobile network to compensate for the occurrence of the events.
  • the problem of the current approach is that the communications are done personally by the people working in the different organizations, so it is a slow and tedious process that entails human time and effort.
  • a method in a context information provider node, wherein the context information provider node is in communication with a network.
  • the method comprises determining information relating to an event; and transmitting the information to a Network Exposure Function, NEF, in the network.
  • NEF Network Exposure Function
  • a method performed by a Network Exposure Function, NEF, in a network comprises receiving information relating to an event from a context information provider; and initiating a network adjustment responsive to the information relating to the event.
  • NEF Network Exposure Function
  • a method in a network function in a network comprises receiving information relating to an event from a network exposure function, wherein the event is of a first type; and initiating network adjustments corresponding to the first type, responsive to receiving the information relating to the event.
  • a method in a network function in a network comprises transmitting an indication of an intent associated with a type of event to a network exposure function.
  • a context information provider node wherein the context information provider node is in communication with a network.
  • the context information provider node comprises processing circuitry configured to: determine information relating to an event; and transmit the information to a Network Exposure Function, NEF, in the network.
  • NEF Network Exposure Function
  • NEF in a network.
  • the NEF comprises processing circuitry configured to receive information relating to an event from a context information provider; and initiate a network adjustment responsive to the information relating to the event.
  • a network function in a network comprises processing circuitry configured to: receive information relating to an event from a network exposure function, wherein the event is of a first type; and initiate network adjustments corresponding to the first type, responsive to receiving the information relating to the event.
  • a network function in a network comprises processing circuitry configured to: transmit an indication of an intent associated with a type of event to a network exposure function.
  • Figure 1 illustrates a 5G network architecture with point to point representation
  • Figure 2 illustrates a method in a context information provider node which is in communication with a network
  • Figure 3 illustrates a signalling diagram illustrating an exchange of capabilities information
  • Figure 4 illustrates a method in an NEF according to some embodiments
  • Figure 5 illustrates an example of a signalling diagram according to some embodiments
  • Figure 6 illustrates an example of a signalling diagram according to some embodiments
  • Figure 7 illustrates an example signalling diagram for an electricity failure event
  • Figure 8 illustrates an example signalling diagram for an electricity failure event
  • Figure 9 illustrates an example signalling diagram for a demonstration event
  • Figure 10 illustrates an example signalling diagram for a demonstration event
  • Figure 1 1 illustrates an example signalling diagram for a fire event
  • Figure 12 illustrates an example signalling diagram for a fire event
  • FIG 13 illustrates a context information provider (CIP) node comprising processing circuitry (or logic);
  • IP context information provider
  • FIG 14 illustrates a Network Exposure Function (NEF) comprising processing circuitry (or logic);
  • NEF Network Exposure Function
  • Figure 15 illustrates a Network Function (NF) comprising processing circuitry (or logic);
  • Figure 16 illustrates a Network Function (NF) comprising processing circuitry (or logic);
  • Hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analogue) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and/or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • Embodiments described herein provide methods and apparatuses that make use of collaboration between an Application Sever Provider and the Network Service Provider.
  • the T8 interface is enhanced to support the provisioning of contextual information relating to events. Enhancements may also be made to the interfaces, for example, Npcf, Nsmf, Nnwdaf, N4, for example, to disperse the contextual information to the packet core nodes PCF, UPF, SMF and NWDAF.
  • Figure 2 illustrates a method in a context information provider node which is in communication with a network.
  • the context information provider (CIP) node may act as an Application Server, and may be in communication with the network exposure function (NEF).
  • NEF network exposure function
  • the term NEF will be used for clarity. However, it will be appreciated that any network function in a service based architecture network providing the means to securely expose the services and capabilities in previous or future network architectures may be used.
  • the SCEF may be used.
  • the CIP node may make use of the T8 interface to communicate with the NEF.
  • the CIP node itself may be operated by an entity such as for example an electric power supplier, national meteorological service, police department, fire department, etc. These entities may make use of the CIP node to alert the network accordingly of any events that they may be aware of.
  • the CIP node may act as a SCS/AS node.
  • a local council may own and run a CIP node.
  • This CIP node may be configured to receive signals from sensors, for example traffic cameras, and/or may be configured to receive user input.
  • the CIP node determines information relating to an event.
  • an event may comprise for example, a football match, earthquake security breach or a traffic jam.
  • an event may comprise any event for which the network may be optimised for use.
  • the CIP node may receive an indication from one or more sensors indicating that the event has occurred or will occur.
  • the CIP node may determine, based on traffic camera signals, that an accident has occurred on a particular highway.
  • the CIP node may receive a user input indicating that the environmental event has occurred or will occur. For example, an owner of the CIP node may input information into the CIP node to register that roadworks are happening on a particular date, which might lead to a higher level of traffic in that area during that time.
  • the CIP node may then determine the information relating to the event.
  • the CIP node transmits the information to a Network Exposure Function, NEF in the network.
  • NEF Network Exposure Function
  • the information may be transmitted over a T8 interface as illustrated in Figure 1.
  • the information may comprise contextual information.
  • the information may comprise an indication of a type of event associated with the event.
  • a parameter EventID may be provided which may indicate the type of event.
  • the EventID may be “electricity failure”, “football match”, “demonstration”, to list a few non-exhaustive examples.
  • the information may comprise values of one or more parameters associated with the event.
  • parameters such as a timestamp associated with the event (“timestamp”), a location of the event (“location”), and an estimated duration of the event (“estimated duration”) may be provided.
  • timestamp a timestamp associated with the event
  • location a location of the event
  • estimated duration an estimated duration of the event
  • the values of each parameter are provided in the information along with the type of parameter, for example in a tuple (parameter-type, parameter-value).
  • An example of information provided by the CIP node may therefore be for an accident that has occurred on a highway (Highway A): Event ID: traffic accident; “timestamp”, 10.46 10/11/19; “location”, highway A - junction 6,“estimated duration”, 3 hour delay.
  • Figure 3 illustrates a signalling diagram illustrating an exchange of capabilities information.
  • the CIP node 300 may be configured to, in step 301 , transmit to the NEF 310 an indication one or more types of environmental event that the CIP node is capable of reporting on.
  • the CIP node 300 may transmit to the NEF 310 through the Nnef interface the capabilities of information that can be exchanged between them.
  • the CIP node 300 may transmit to the NEF 310 the following information:
  • a parameter that identifies the CIP node for example scsASId. This field may be common to all Nnef northbound APIs.
  • Event-ID indicates a type of event. Examples of an Event ID may comprise: a mass-event, an environmental failure, a security incident, a disaster, etc.
  • a list of one or more parameter types that the CIP node 300 can associate to each Event ID for example, ’’timestamp”, “location” or“estimated duration”, etc.
  • the CIP node 300 may also provide what parameter values it supports for each of the parameter types associated with each Event-IDs. For example, if the CIP node only covers a certain location it can provide this information to the operator in this step.
  • the CIP node 300 may then receive, from the NEF 310, a subscription request indicating a subset of the one or more types of environmental event. For example, based on the received an indication one or more types of environmental event that the CIP is capable of reporting on, the NEF may select a subset of those types of event that it wishes to receive information about. The subset may comprise all of the types of event in the indication or may comprise not all of the types of event in the indication.
  • the CIP node 300 may then register the subscription of the NEF to particular types of event in the subset.
  • the CIP node may then perform the step of transmitting the information to the NEF responsive to the event being of a type in the subset.
  • the network operator may ask the CIP node for certain Event IDs and associated parameter types and parameter values.
  • the operator using the NEF may provide to the CIP node the following information:
  • a list of parameter types that the network operator would like to receive associated with each Event ID e.g. “timestamp”, “location”, “estimated duration”, etc.
  • the network operator may also provide what parameter values it would like to receive for each Event-ID. For example, if the operator only wants to receive information relating to events occurring within a certain location, it may provide this information to the CIP node in this step.
  • the NEF 310 may then distribute the information into the network, or may initiate appropriate adjustments to the network.
  • Figure 4 illustrates a method in an NEF according to some embodiments.
  • the NEF 310 receives information relating to an environmental event from a context information provider.
  • the information may comprise information as described with reference to Figure 2.
  • the NEF 310 may initiate a network adjustment responsive to the information relating to the environmental event.
  • Figure 5 illustrates an example of a signalling diagram according to some embodiments.
  • the NEF 310 receives information relating to an environmental event from a CIP node 300.
  • the information may comprise the EventID and the parameters associated with the EventID.
  • the NEF 310 transmits the information relating to the event to one or more network functions (for example network function 500).
  • the one or more network functions may be subscribed to receive information about a type of event, wherein the event is of the type of event.
  • the NF 500 may have sent a subscription request to the NEF 310 to receive information relating to events of certain types.
  • the subscription request may comprise a list of EventIDs that he NF 500 wishes to subscribe to.
  • the NEF 310 may then expose this information relating to an event to network functions that are subscribed to the Event-ID.
  • the Network Function may then initiate network adjustments corresponding to the EventID of the event.
  • the NEF may have access to a predetermined rule associated with the EventID.
  • the rule may state that the Network increases resources in the area of the event.
  • the NF 500 may then perform actions according to the rule associated with the EventID.
  • the network functions that are interested in receiving information relating to events of a particular type from the NEF can subscribe previously to those events.
  • the PCF and the Orchestrator may subscribe to events with“electricity outage” EventID, since they are events that may require an instant adjustment from the network (the PCF may have configured policies defining how to react to such an event).
  • the NWDAF may subscribe to “traffic jam” events, since they are events that require some analytics and processing to determine the optimal actions to take.
  • Figure 6 illustrates an example of a signalling diagram according to some embodiments.
  • the CIP node 300 determines information relating to an event.
  • the information may comprise the EventID and the parameters associated with the event ID.
  • the event has an EventID of“EventID-A”
  • the NEF 310 receives information relating to an event from a CIP node 300.
  • the NEF 310 may then exposure the information using intent based network towards an application.
  • a network function in this example the OSS 610, may use Intent Based Networking to create an intent.
  • An example of intent may be“I want to grow if an EventID-A occurs”.
  • An intent may therefore define an outcome in the network that ought to be implemented in response to the occurrence of, for example, an event of a particular type, or an event of a particular type in a particular location etc.
  • the OSS 610 or another network function may therefore be configured to transmit an indication of an intent associated with a type of event to the NEF 310.
  • the NEF 310 receives an indication from a network function of an intent associated with a type of event.
  • the NEF 310 receives the indication from the OSS 610.
  • the intent in this example is“I want to grow if an EventID-A occurs”.
  • step 603 may be performed at any time.
  • the indication of the intent may be received before the event occurs.
  • the NEF 310 may then validate the intent. For example, the NEF 310 may compiles the intent and translate into the following:
  • Network Resource Network Function (s) that may scale.
  • Constraints Number of NF that may be scaled. One unit for example. Criteria : EventID-A
  • step 604 responsive to the event indicated in step 602 being of the type of event indicated in the intent, the NEF 310 transmits instructions to perform the network adjustment to implement the intent in the network.
  • the NEF 310 transmits the instruction“scale out” to the NF 600 in step 604.
  • an intent may specify that an event type has to occur in a particular location.
  • the NEF 310 may then only send instructions to implement the network adjustments responsive to the event type occurring in the location indicated in the intent.
  • Figure 7 illustrates an example signalling diagram for an electricity failure event.
  • the Network Function Virtualisation Orchestrator (NFVO) 700 has subscribed to the NEF to receive information relating to events having an EventID of “electricity failure”. The mobile operator may then configure the NFVO 700 to trigger certain orchestration actions (for example, migrating affected resources) when an electricity failure occurs.
  • NFVO Network Function Virtualisation Orchestrator
  • the CIP 300 determines information relating to the occurrence of an event.
  • the CIP node 300 receives an indication from a sensor (for example a power plane) handled by the electricity operator operating the CIP node 300.
  • the indication from the sensor indicates that an electricity failure has occurred.
  • the CIP node 300 may therefore determine the following information:
  • Event-ID electricity failure
  • the NEF 310 receives the information from the CIP and may expose this information to the elements of the network that are subscribed to the Event-ID.
  • the NFVO 700 receives the information from the NEF 310. The transmission of the information to the NFVO may therefore initiate a network adjustment. The NFVO 700 may then migrate the function of areal to another area and may move the traffic to the other area. This network adjustment may therefore compensate for the occurrence of the electricity failure.
  • Figure 8 illustrates an example signalling diagram for an electricity failure event.
  • the NFVO 700 may transmit to the NEF the actions supported by NFVO for example, scale, migrate, etc.
  • the CIP 300 determines information relating to the occurrence of an event.
  • the CIP node 300 receives an indication from a sensor (for example a power plane) handled by the electricity operator operating the CIP node 300.
  • the indication from the sensor indicates that an electricity failure has occurred.
  • the CIP node 300 may therefore determine the following information:
  • Event-ID electricity failure
  • the NEF 310 receives the information from the CIP and may expose this information to the elements of the network
  • the OSS 610 may create an intent.
  • the intent is the following “I want to migrate if an Electricity-Failure occurs in area 1 from area 1 to area 2”.
  • step 803 may be performed at any time, and may be performed before step 801.
  • the NEF 310 may then validate the intent. For example, the NEF 310 may compile the intent and translate into the following:
  • step 804 responsive to the event indicated in step 802 being of the type of event indicated in the intent, the NEF 310 transmits instructions to perform a network adjustment to implement the intent in the network.
  • the NEF 310 transmits the instruction“scale out” to the NFVO 700 in step 804.
  • Figure 9 illustrates an example signalling diagram for a demonstration event.
  • the Network Function Virtualisation Orchestrator (NFVO) 700 and the PCF 900 have subscribed to the NEF to receive information relating to events having an EventID of“demonstration”.
  • the mobile operator may then configure the PCF 900 to trigger certain policies (e.g. prioritize premium users) and the NFVO 700 to trigger certain orchestration actions (e.g. deploy more resources) when a mass- event such as a demonstration occurs.
  • the CIP 300 determines information relating to the occurrence of an event.
  • the CIP node 300 a user input from a police department which has approved a legal demonstration.
  • the CIP node 300 may therefore determine the following information:
  • the NEF 310 receives the information from the CIP and may expose this information to the elements of the network that are subscribed to the Event-ID (for example the PCF 900 and the NFVO 700 in this case).
  • the Event-ID for example the PCF 900 and the NFVO 700 in this case.
  • the NFVO 700 receives the information from the NEF 310.
  • the transmission of the information to the NFVO may therefore initiate a network adjustment.
  • the NFVO 700 may then create more resources in area 1.
  • the NFVO may scale area 1 on the date 21/06/2019. This network adjustment may therefore compensate for the occurrence of the demonstration allowing for more resources to be available where lots of people will be present.
  • the PCF 900 receives the information from the NEF 310.
  • the transmission of the information to the PCF 900 may therefore initiate a network adjustment.
  • the PCF may provision Quality of Service policies to“Gold” level users thereby prioritising those users having mobile devices which are subscribed to a higher level of service in the network.
  • Figure 10 illustrates an example signalling diagram for a demonstration.
  • the NFVO 700 may transmit to the NEF the actions supported by NFVO for example, scale, migrate, etc.
  • the PCF 900 may also transmit to the NEF 310 the actions supported by the PCF 900
  • the CIP node 300 determines information relating to the occurrence of an event.
  • the CIP node 300 a user input from a police department which has approved a legal demonstration.
  • the CIP node 300 may therefore determine the following information:
  • the NEF 310 receives the information from the CIP and may expose this information to the elements of the network.
  • the OSS 610 may create one or more intents.
  • intents there are two intents:
  • step 1003 may be performed at any time, and may be performed before step 1001.
  • the NEF 310 may then validate the intents. For example, the NEF 310 may compile the intents and translate into the following: Network Resource : NFVO.
  • step 1004 responsive to the event indicated in step 1002 being of the type of event indicated in the intent, the NEF 310 transmits instructions to perform a network adjustment to implement the intent in the network.
  • the NEF 310 transmits the instruction“migrate” to the NFVO 700 in step 1004, and the instruction“prioritize gold users” to the PCF 900 in step 1004.
  • the NFVO 700 and PCF 900 may then implement the instructions in the network to implement the network adjustments.
  • Figure 11 illustrates an example signalling diagram for a fire event.
  • the PCF 900 has subscribed to the NEF 310 to receive information relating to events having an EventID of “fire”. The mobile operator may then configure the PCF 900 to determine the subscribers in the area of the fire and alert them.
  • the CIP 300 determines information relating to the occurrence of an event.
  • the CIP node 300 may receive an alarm from a fire brigade comprising information relating to the fire.
  • the CIP node 300 may therefore determine the following information:
  • the CIP node 310 may then transmit the information to the NEF 310.
  • the NEF 310 receives the information from the CIP node 310 and may expose this information to the elements of the network that are subscribed to the Event-ID (for example the PCF 900 in this case).
  • the PCF 900 receives the information from the NEF 310.
  • the transmission of the information to the PCF 900 may therefore initiate a network adjustment.
  • the PCF 900 may then be configured by the mobile operator to ask the UDR 1 100 for identifications of subscribers that are near the Access Node where fire incident has happened.
  • the PCF 900 may receive the list of subscribers from the UDR 1 100.
  • the PCF 900 may decide to alert the subscribers as to the fire risk.
  • the PCF 900 may transmit, in step 1 105, an SMS or DoNAS indication to all subscribers in the area or, subscribers that have been in the area within a predetermined time, for example, within the last month
  • Figure 12 illustrates an example of a signalling diagram for a fire event.
  • the PCF 900 may transmit to the NEF 310 the actions supported by PCF for example,“notify” etc.
  • the CIP node 300 determines information relating to the occurrence of an event.
  • the CIP node 300 may receive an alarm from a fire brigade comprising information relating to a fire event.
  • the CIP node 300 may therefore determine the following information:
  • the NEF 310 receives the information from the CIP node 300 and may expose this information to the elements of the network.
  • the OSS 610 may create one or more intents.
  • an intent in the following: “I want to notify to all users in the area if fire occurs”
  • step 1203 may be performed at any time, and may be performed before step 1201.
  • the NEF 310 may then validate the intent. For example, the NEF 310 may compile the intent and translate into the following:
  • step 1204 responsive to the event indicated in step 1202 being of the type of event indicated in the intent, the NEF 310 transmits instructions to perform a network adjustment to implement the intent in the network.
  • the NEF 310 transmits the instruction“notify users in the area (area 1 )” to the PCF 900 in step 1204.
  • step 1205 the PCF 900 retrieves from the UDR 1 100 the identification of subscribers in area 1.
  • the PCF 900 may decide to alert the subscribers as to the fire risk.
  • the PCF 900 may transmit a SMS or DoNAS indication to all subscribers in the area or, subscribers that have been in the area within a predetermined time, for example, within the last month.
  • Figure 13 illustrates a context information provider (CIP) node 1300 comprising processing circuitry (or logic) 1301.
  • the CIP node 1300 may be configured to perform the methods described with reference to CIP node 300 above.
  • the processing circuitry 1301 controls the operation of the CIP node 1300 and can implement the method described herein in relation to an CIP node 1300.
  • the CIP may be configured to communicate with a core network, for example a 5G core network.
  • the CIP node 1300 may be configured to communicate with a Network Exposure Function in a service based architecture core network.
  • the processing circuitry 1301 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the CIP node 1300 in the manner described herein.
  • the processing circuitry 1301 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the CIP node 1300.
  • the processing circuitry 1301 of the CIP node 1300 is configured to: determine information relating to an event; and transmit the information to a Network Exposure Function, NEF, in the network.
  • NEF Network Exposure Function
  • the CIP node 1300 may optionally comprise a communications interface 1302.
  • the communications interface 1302 of the CIP node 1300 can be for use in communicating with other nodes, such as other virtual nodes.
  • the communications interface 1302 of the CIP node 1300 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the processing circuitry 1301 of CIP node 1300 may be configured to control the communications interface 1302 of the CIP node 1300 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the CIP node 1300 may comprise a memory 1303.
  • the memory 1303 of the CIP node 1300 can be configured to store program code that can be executed by the processing circuitry 1301 of the CIP node 1300 to perform the method described herein in relation to the CIP node 1300.
  • the memory 1303 of the CIP node 1300 can be configured to store any requests, resources, information, data, signals, or similar that are described herein.
  • the processing circuitry 1301 of the CIP node 1300 may be configured to control the memory 1303 of the CIP node 1300 to store any requests, resources, information, data, signals, or similar that are described herein.
  • FIG 14 illustrates a Network Exposure Function (NEF) 1400 comprising processing circuitry (or logic) 1401.
  • NEF Network Exposure Function
  • the NEF 1400 may therefore comprise one or more servers, switches, storage devices and/or cloud computing infrastructure that run the software and/or processes.
  • the NEF 1400 may comprise the NEF 310 as described above.
  • the processing circuitry 1401 controls the operation of the NEF 1400 and can implement the method described herein in relation to an NEF 1400.
  • the processing circuitry 1401 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the NEF 1400 in the manner described herein.
  • the processing circuitry 1401 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the NEF 1400 or NEF 310.
  • the processing circuitry 1401 of the NEF 1400 is configured to: receive information relating to an event from a context information provider node; and initiate a network adjustment responsive to the information relating to the event.
  • the NEF 1400 may optionally comprise a communications interface 1402.
  • the communications interface 1402 of the NEF 1400 can be for use in communicating with other nodes, such as other virtual nodes or network functions.
  • the communications interface 1402 of the NEF 1400 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the processing circuitry 1401 of NEF 1400 may be configured to control the communications interface 1402 of the NEF 1400 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the NEF 1400 may comprise a memory 1403.
  • the memory 1403 of the NEF 1400 can be configured to store program code that can be executed by the processing circuitry 1401 of the NEF 1400 to perform the method described herein in relation to the NEF 1400.
  • the memory 1403 of the NEF 1400 can be configured to store any requests, resources, information, data, signals, or similar that are described herein.
  • the processing circuitry 1401 of the NEF 1400 may be configured to control the memory 1403 of the NEF 1400 to store any requests, resources, information, data, signals, or similar that are described herein.
  • Figure 15 illustrates a Network Function (NF) 1500 comprising processing circuitry (or logic) 1501. .
  • NF Network Function
  • the NF 1500 may comprise one or more virtual machines running different software and/or processes.
  • the NF 1500 may therefore comprise one or more servers, switches, storage devices and/or cloud computing infrastructure that run the software and/or processes.
  • the NF 1500 may comprise any of the network functions above, for example, NF 500, NFVO 700 and PCF 900.
  • the processing circuitry 1501 controls the operation of the NF 1500 and can implement the method described herein in relation to an NF 1500.
  • the processing circuitry 1501 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the NF 1500 in the manner described herein.
  • the processing circuitry 1501 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the NF 1500.
  • the processing circuitry 1501 of the NF 1500 is configured to: receive information relating to an event from a network exposure function, wherein the event is of a first type; and initiate network adjustments corresponding to the first type, responsive to receiving the information relating to the event.
  • the NF 1500 may optionally comprise a communications interface 1502.
  • the communications interface 1502 of the NF 1500 can be for use in communicating with other nodes, such as other virtual nodes or network functions.
  • the communications interface 1502 of the NF 1500 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the processing circuitry 1501 of NF 1500 may be configured to control the communications interface 1502 of the NF 1500 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the NF 1500 may comprise a memory 1503.
  • the memory 1503 of the NF 1500 can be configured to store program code that can be executed by the processing circuitry 1501 of the NF 1500 to perform the method described herein in relation to the NF 1500.
  • the memory 1503 of the NF 1500 can be configured to store any requests, resources, information, data, signals, or similar that are described herein.
  • FIG. 16 illustrates a Network Function (NF) 1600 comprising processing circuitry (or logic) 1601.
  • NF Network Function
  • the NF 1600 may comprise one or more virtual machines running different software and/or processes.
  • the NF 1600 may therefore comprise one or more servers, switches, storage devices and/or cloud computing infrastructure that run the software and/or processes.
  • the NF 1600 may comprise the OSS 610 as described above.
  • the processing circuitry 1601 controls the operation of the NF 1600 and can implement the method described herein in relation to an NF 1600.
  • the processing circuitry 1601 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the NF 1600 in the manner described herein.
  • the processing circuitry 1601 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the NF 1600.
  • the processing circuitry 1601 of the NF 1600 is configured to: transmit an indication of an intent associated with a type of event to a network exposure function.
  • the NF 1600 may optionally comprise a communications interface 1602.
  • the communications interface 1602 of the NF 1600 can be for use in communicating with other nodes, such as other virtual nodes or network functions.
  • the communications interface 1602 of the NF 1600 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the processing circuitry 1601 of NF 1600 may be configured to control the communications interface 1602 of the NF 1600 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
  • the NF 1600 may comprise a memory 1603.
  • the memory 1603 of the NF 1600 can be configured to store program code that can be executed by the processing circuitry 1601 of the NF 1600 to perform the method described herein in relation to the NF 1600.
  • the memory 1603 of the NF 1600 can be configured to store any requests, resources, information, data, signals, or similar that are described herein.
  • the processing circuitry 1601 of the NF 1600 may be configured to control the memory 1603 of the NF 1600 to store any requests, resources, information, data, signals, or similar that are described herein.

Abstract

Embodiments described herein provide methods and apparatuses for providing context information relating to an event to a network. A method in a context information provider node, wherein the context information provider node is in communication with a network, comprises determining information relating to an event; and transmitting the information to a Network Exposure Function, NEF, in the network.

Description

METHODS AND APPARATUS FOR PROVIDING CONTEXT INFORMATION TO A NETWORK
Technical Field
Embodiments described herein relate to methods and apparatuses for providing context information relating to an event to a network. In particular, the network may adjust to compensate for an event that may have a detrimental effect on the network.
Background
Figure 1 illustrates a 5G network architecture with point to point representation. Network Functions correspond to the Core Network Control Plane and they may use Service Based Architecture (SBA) interfaces to communicate with each other.
The Packet Flow Description Function (PFDF) in 5G has been included inside the Network Exposure Function (NEF) to reduce the number of individual network functions in 5G. The PFDF handles the Packet Flow Descriptions (PFDs) associated with application identifier(s) and transfers them to the Session Management Function (SMF) via (NG) Gw interface. The SMF may then sends these PFDs towards the User Plane Function (UPF) through the N4 PFD Management procedure to enable the UPF to perform accurate application detection when the PFDs are managed by a 3rd party service provider.
The T8 interface (which may be defined as in Rel 15 29.122) is between the SCS/AS (Service Capability Server/Application Server) and the NEF in the case of 5G networks, or the SCEF (Service Capability Exposure Function) in the case of 4G networks. It specifies RESTful Application Program Interfaces (APIs) that allow the SCS/AS to access the services and capabilities provided by the 3GPP network entities and securely exposed by the SCEF/NEF. One of those APIs is a monitoring event API (as described in subclause 4.4.6.1 in 23.682) where the SCS/AS can subscribe to some monitoring events like UE loss of connectivity, UE location reporting, UE roaming status, communication failure, change of I MEI-I MSI association. Other APIs like the NetworkParameterConfiguration API allow the SCS/AS to send the suggested network parameters to influence certain aspects of U E/network behavior. The Policy and Charging Rules Function (PCF) is a functional element that performs policy control decision and flow-based charging control. The PCF may provide network control regarding the service data flow detection.
The User Plane Function (UPF) encompasses service data flow detection, policy enforcement and flow-based charging functionalities, an anchor point for lntra-/lnter- RAT mobility (when applicable), an external IP point of interconnect, packet routing & forwarding, Quality of Service (QoS) handling for the user plane, packet inspection and Policy and Charging Control (PCC) rule enforcement, lawful intercept (User Plane (UP) collection), roaming interface (UP), traffic counting and reporting.
In Rel 15, 22.261 , section 6.1 1 defines the following requirement related to the usage of external or contextual information for network optimization purposes:
“The 5G system shall support network resource utilization efficiently and network optimization based on system information. The information gathered by sensors, the utilized access technologies, the application context, and the application traffic characteristics can provide useful information to the applications installed in the UE and can also help the 5G system utilize resources in an efficient and optimized way.”
Contextual network is a term that refers to the usage of contextual information for network control purposes. It comes from the established term “contextual advertising”, which refers to the use of contextual information (e.g. location) to show relevant advertisements to the users.
Examples of contextual information that may be leveraged in 5G (and the source of such information) are:
If there are a large amount of people gathering together e.g. in a demonstration, concert, etc. This information may be handled by city councils, local administrations, etc.
If there is an electricity outage in a certain part of a city or other larger zones. This information may be handled by energy providers. If there is a traffic jam in a certain highway, if a certain highway is temporally closed, etc. This information may be handled by the governments, automobile traffic management organizations, etc.
If there is a catastrophic event such as a fire, earthquake, etc. This information may be handled by governments, geographic or nature protection organizations, etc.
Currently, when there is an event that may have some detrimental effect on the network, and which may be compensated for with special performance or capacity requirements (for example, concerts, demonstrations or any of the events mentioned above).
The organizations in charge of, or who may be aware of the occurrence of these events (for example, local councils, governments, etc.) may then contact the mobile network operators to alert them as to the occurrence of the event. The mobile network operators may then adapt the mobile network to compensate for the occurrence of the events. The problem of the current approach is that the communications are done personally by the people working in the different organizations, so it is a slow and tedious process that entails human time and effort.
Additionally, there may be other events that may have an effect on the performance of the mobile networks, which are not currently communicated to the mobile operators. For example, electricity outages. During an electricity outage, the mobile network equipment in the zone stops working. In this circumstance, it is currently the mobile operator employees that must realize that there is an electricity outage in order to react accordingly to adapt the network to such conditions.
Similarly, for automotive events (for example, traffic jams, closed roads, etc.) operators can detect that the users’ mobility patterns change, but they may have no knowledge of what is causing the change in the users’ mobility patterns, and therefore they do not know what the optimal way is to react to the changes in mobility patterns. In short, current mobile network solutions do not allow for leveraging contextual information about events such as the ones described above (concerts, demonstrations, electricity outages, etc.) in an automatic way. This leads to inefficient network control and orchestration actions when such events take place, since in most cases the operator’s employees are the ones that are required to realize that such event is happening, and may then reconfigure the network manually.
Summary
According to some embodiments there is provided a method, in a context information provider node, wherein the context information provider node is in communication with a network. The method comprises determining information relating to an event; and transmitting the information to a Network Exposure Function, NEF, in the network.
According to some embodiments there is provided a method performed by a Network Exposure Function, NEF, in a network. The method comprises receiving information relating to an event from a context information provider; and initiating a network adjustment responsive to the information relating to the event.
According to some embodiments there is provided a method in a network function in a network. The method comprises receiving information relating to an event from a network exposure function, wherein the event is of a first type; and initiating network adjustments corresponding to the first type, responsive to receiving the information relating to the event.
According to some embodiments there is provided a method in a network function in a network. The method comprises transmitting an indication of an intent associated with a type of event to a network exposure function.
According to some embodiments there is provided a context information provider node, wherein the context information provider node is in communication with a network. The context information provider node comprises processing circuitry configured to: determine information relating to an event; and transmit the information to a Network Exposure Function, NEF, in the network. According to some embodiments there is provided a Network Exposure Function, NEF, in a network. The NEF comprises processing circuitry configured to receive information relating to an event from a context information provider; and initiate a network adjustment responsive to the information relating to the event.
According to some embodiments there is provided a network function in a network. The network function comprises processing circuitry configured to: receive information relating to an event from a network exposure function, wherein the event is of a first type; and initiate network adjustments corresponding to the first type, responsive to receiving the information relating to the event.
According to some embodiments there is provided a network function in a network. The network function comprises processing circuitry configured to: transmit an indication of an intent associated with a type of event to a network exposure function.
Brief Description of the Figures
For a better understanding of the embodiments of the present disclosure, and to show how it may be put into effect, reference will now be made, by way of example only, to the accompanying drawings, in which:
Figure 1 illustrates a 5G network architecture with point to point representation;
Figure 2 illustrates a method in a context information provider node which is in communication with a network;
Figure 3 illustrates a signalling diagram illustrating an exchange of capabilities information;
Figure 4 illustrates a method in an NEF according to some embodiments;
Figure 5 illustrates an example of a signalling diagram according to some embodiments; Figure 6 illustrates an example of a signalling diagram according to some embodiments;
Figure 7 illustrates an example signalling diagram for an electricity failure event;
Figure 8 illustrates an example signalling diagram for an electricity failure event;
Figure 9 illustrates an example signalling diagram for a demonstration event; Figure 10 illustrates an example signalling diagram for a demonstration event;
Figure 1 1 illustrates an example signalling diagram for a fire event;
Figure 12 illustrates an example signalling diagram for a fire event;
Figure 13 illustrates a context information provider (CIP) node comprising processing circuitry (or logic);
Figure 14 illustrates a Network Exposure Function (NEF) comprising processing circuitry (or logic);
Figure 15 illustrates a Network Function (NF) comprising processing circuitry (or logic); Figure 16 illustrates a Network Function (NF) comprising processing circuitry (or logic);
Description All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.
The following sets forth specific details, such as particular embodiments or examples for purposes of explanation and not limitation. It will be appreciated by one skilled in the art that other examples may be employed apart from these specific details. In some instances, detailed descriptions of well-known methods, nodes, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more nodes using hardware circuitry (e.g., analog and/or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc.) and/or using software programs and data in conjunction with one or more digital microprocessors or general purpose computers. Nodes that communicate using the air interface also have suitable radio communications circuitry. Moreover, where appropriate the technology can additionally be considered to be embodied entirely within any form of computer-readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.
Hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analogue) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and/or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions. Embodiments described herein provide methods and apparatuses that make use of collaboration between an Application Sever Provider and the Network Service Provider. In particular, in some embodiments, the T8 interface is enhanced to support the provisioning of contextual information relating to events. Enhancements may also be made to the interfaces, for example, Npcf, Nsmf, Nnwdaf, N4, for example, to disperse the contextual information to the packet core nodes PCF, UPF, SMF and NWDAF.
Figure 2 illustrates a method in a context information provider node which is in communication with a network.
The context information provider (CIP) node may act as an Application Server, and may be in communication with the network exposure function (NEF). In this description and the accompanying claims the term NEF will be used for clarity. However, it will be appreciated that any network function in a service based architecture network providing the means to securely expose the services and capabilities in previous or future network architectures may be used. For example, the SCEF may be used.
For example, the CIP node may make use of the T8 interface to communicate with the NEF.
The CIP node itself may be operated by an entity such as for example an electric power supplier, national meteorological service, police department, fire department, etc. These entities may make use of the CIP node to alert the network accordingly of any events that they may be aware of. In the context of the T8 interface the CIP node may act as a SCS/AS node.
For example, a local council may own and run a CIP node. This CIP node may be configured to receive signals from sensors, for example traffic cameras, and/or may be configured to receive user input.
In step 201 , the CIP node determines information relating to an event. As previously mentioned, an event may comprise for example, a football match, earthquake security breach or a traffic jam. In general, an event may comprise any event for which the network may be optimised for use. For example, the CIP node may receive an indication from one or more sensors indicating that the event has occurred or will occur.
For example, using the example of a local council owned CIP node receiving signals from traffic cameras, the CIP node may determine, based on traffic camera signals, that an accident has occurred on a particular highway.
Additionally or alternatively, the CIP node may receive a user input indicating that the environmental event has occurred or will occur. For example, an owner of the CIP node may input information into the CIP node to register that roadworks are happening on a particular date, which might lead to a higher level of traffic in that area during that time.
From the indication from one or more sensors, and or the user input, the CIP node may then determine the information relating to the event.
In step 202, the CIP node transmits the information to a Network Exposure Function, NEF in the network. For example, the information may be transmitted over a T8 interface as illustrated in Figure 1.
The information may comprise contextual information. For example, the information may comprise an indication of a type of event associated with the event. For example, a parameter EventID may be provided which may indicate the type of event. For example, the EventID may be “electricity failure”, “football match”, “demonstration”, to list a few non-exhaustive examples.
The information may comprise values of one or more parameters associated with the event. For example, parameters such as a timestamp associated with the event (“timestamp”), a location of the event (“location”), and an estimated duration of the event (“estimated duration”) may be provided. In some examples, the values of each parameter are provided in the information along with the type of parameter, for example in a tuple (parameter-type, parameter-value).
An example of information provided by the CIP node may therefore be for an accident that has occurred on a highway (Highway A): Event ID: traffic accident; “timestamp”, 10.46 10/11/19; “location”, highway A - junction 6,“estimated duration”, 3 hour delay.
Figure 3 illustrates a signalling diagram illustrating an exchange of capabilities information.
In this example, the CIP node 300 may be configured to, in step 301 , transmit to the NEF 310 an indication one or more types of environmental event that the CIP node is capable of reporting on.
For example, the CIP node 300 may transmit to the NEF 310 through the Nnef interface the capabilities of information that can be exchanged between them. For example, the CIP node 300 may transmit to the NEF 310 the following information:
A parameter that identifies the CIP node, for example scsASId. This field may be common to all Nnef northbound APIs.
A list of one or more Event IDs that the CIP node can provide information relating to. As previously mentioned, and Event-ID indicates a type of event. Examples of an Event ID may comprise: a mass-event, an environmental failure, a security incident, a disaster, etc.
A list of one or more parameter types that the CIP node 300 can associate to each Event ID, for example, ’’timestamp”, “location” or“estimated duration”, etc.
In some examples, the CIP node 300 may also provide what parameter values it supports for each of the parameter types associated with each Event-IDs. For example, if the CIP node only covers a certain location it can provide this information to the operator in this step. In step 302, the CIP node 300 may then receive, from the NEF 310, a subscription request indicating a subset of the one or more types of environmental event. For example, based on the received an indication one or more types of environmental event that the CIP is capable of reporting on, the NEF may select a subset of those types of event that it wishes to receive information about. The subset may comprise all of the types of event in the indication or may comprise not all of the types of event in the indication.
The CIP node 300 may then register the subscription of the NEF to particular types of event in the subset. The CIP node may then perform the step of transmitting the information to the NEF responsive to the event being of a type in the subset.
Alternatively, the network operator (for example via the NEF) may ask the CIP node for certain Event IDs and associated parameter types and parameter values. In this case the operator (using the NEF) may provide to the CIP node the following information:
A List of Event IDs that the network operator wants to receive;
A list of parameter types that the network operator would like to receive associated with each Event ID, e.g. “timestamp”, “location”, “estimated duration”, etc.
Optionally, the network operator may also provide what parameter values it would like to receive for each Event-ID. For example, if the operator only wants to receive information relating to events occurring within a certain location, it may provide this information to the CIP node in this step.
Once the NEF 310 has received the information from the CIP, the NEF may then distribute the information into the network, or may initiate appropriate adjustments to the network.
Figure 4 illustrates a method in an NEF according to some embodiments.
In step 401 , the NEF 310 receives information relating to an environmental event from a context information provider. The information may comprise information as described with reference to Figure 2. In step 402, the NEF 310 may initiate a network adjustment responsive to the information relating to the environmental event.
Figure 5 illustrates an example of a signalling diagram according to some embodiments.
In this example, in step 501 , the NEF 310 receives information relating to an environmental event from a CIP node 300. The information may comprise the EventID and the parameters associated with the EventID.
In this example, in step 502, the NEF 310 transmits the information relating to the event to one or more network functions (for example network function 500).
In this example, the one or more network functions may be subscribed to receive information about a type of event, wherein the event is of the type of event. For example, the NF 500 may have sent a subscription request to the NEF 310 to receive information relating to events of certain types. For example, the subscription request may comprise a list of EventIDs that he NF 500 wishes to subscribe to.
The NEF 310 may then expose this information relating to an event to network functions that are subscribed to the Event-ID.
The Network Function may then initiate network adjustments corresponding to the EventID of the event. For example, the NEF may have access to a predetermined rule associated with the EventID. For example, for a certain EventID the rule may state that the Network increases resources in the area of the event. The NF 500 may then perform actions according to the rule associated with the EventID.
For example, the network functions (NWDAF, PCF, etc.) that are interested in receiving information relating to events of a particular type from the NEF can subscribe previously to those events. For example, the PCF and the Orchestrator may subscribe to events with“electricity outage” EventID, since they are events that may require an instant adjustment from the network (the PCF may have configured policies defining how to react to such an event). While the NWDAF may subscribe to “traffic jam” events, since they are events that require some analytics and processing to determine the optimal actions to take. Figure 6 illustrates an example of a signalling diagram according to some embodiments.
In step 601 , the CIP node 300 determines information relating to an event. . The information may comprise the EventID and the parameters associated with the event ID. In this example, the event has an EventID of“EventID-A”
In step 602, the NEF 310 receives information relating to an event from a CIP node 300. The NEF 310 may then exposure the information using intent based network towards an application.
A network function, in this example the OSS 610, may use Intent Based Networking to create an intent. An example of intent may be“I want to grow if an EventID-A occurs”. An intent may therefore define an outcome in the network that ought to be implemented in response to the occurrence of, for example, an event of a particular type, or an event of a particular type in a particular location etc. The OSS 610 or another network function may therefore be configured to transmit an indication of an intent associated with a type of event to the NEF 310.
In step 603, the NEF 310 receives an indication from a network function of an intent associated with a type of event. In this example, the NEF 310 receives the indication from the OSS 610. The intent in this example is“I want to grow if an EventID-A occurs”.
It will be appreciated that step 603 may be performed at any time. For example, the indication of the intent may be received before the event occurs.
The NEF 310 may then validate the intent. For example, the NEF 310 may compiles the intent and translate into the following:
Network Resource : Network Function (s) that may scale.
Constraints: Number of NF that may be scaled. One unit for example. Criteria : EventID-A
Instruction: scale out. In step 604, responsive to the event indicated in step 602 being of the type of event indicated in the intent, the NEF 310 transmits instructions to perform the network adjustment to implement the intent in the network.
In this example therefore the NEF 310 transmits the instruction“scale out” to the NF 600 in step 604.
It will be appreciated that more complicated intents may be used with more complicated criteria and constraints. For example, an intent may specify that an event type has to occur in a particular location. The NEF 310 may then only send instructions to implement the network adjustments responsive to the event type occurring in the location indicated in the intent.
Figure 7 illustrates an example signalling diagram for an electricity failure event.
In this example, the Network Function Virtualisation Orchestrator (NFVO) 700 has subscribed to the NEF to receive information relating to events having an EventID of “electricity failure”. The mobile operator may then configure the NFVO 700 to trigger certain orchestration actions (for example, migrating affected resources) when an electricity failure occurs.
In step 701 , the CIP 300 determines information relating to the occurrence of an event. In this example, the CIP node 300 receives an indication from a sensor (for example a power plane) handled by the electricity operator operating the CIP node 300. The indication from the sensor indicates that an electricity failure has occurred. The CIP node 300 may therefore determine the following information:
Event-ID: electricity failure
Timestamp: 21/06/2019
Location: area 1
In step 702, the NEF 310 receives the information from the CIP and may expose this information to the elements of the network that are subscribed to the Event-ID. In step 703, the NFVO 700 receives the information from the NEF 310. The transmission of the information to the NFVO may therefore initiate a network adjustment. The NFVO 700 may then migrate the function of areal to another area and may move the traffic to the other area. This network adjustment may therefore compensate for the occurrence of the electricity failure.
Figure 8 illustrates an example signalling diagram for an electricity failure event.
In this example, the NFVO 700 may transmit to the NEF the actions supported by NFVO for example, scale, migrate, etc.
In step 801 , the CIP 300 determines information relating to the occurrence of an event. In this example, the CIP node 300 receives an indication from a sensor (for example a power plane) handled by the electricity operator operating the CIP node 300. The indication from the sensor indicates that an electricity failure has occurred. The CIP node 300 may therefore determine the following information:
Event-ID: electricity failure
Timestamp: 21/06/2019
Location: area 1
In step 802, the NEF 310 receives the information from the CIP and may expose this information to the elements of the network
In step 803, the OSS 610, for example, using Intent Based Networking, may create an intent. In this example the intent is the following “I want to migrate if an Electricity-Failure occurs in area 1 from area 1 to area 2”.
It will be appreciated that step 803 may be performed at any time, and may be performed before step 801.
The NEF 310 may then validate the intent. For example, the NEF 310 may compile the intent and translate into the following:
Network Resource : NFVO.
Constraints: Area 1 to Area 2.
Criteria : Event of the CIP“Electricity Failure” Instructions : migrate.
In step 804, responsive to the event indicated in step 802 being of the type of event indicated in the intent, the NEF 310 transmits instructions to perform a network adjustment to implement the intent in the network.
In this example therefore the NEF 310 transmits the instruction“scale out” to the NFVO 700 in step 804.
Figure 9 illustrates an example signalling diagram for a demonstration event.
In this example, the Network Function Virtualisation Orchestrator (NFVO) 700 and the PCF 900 have subscribed to the NEF to receive information relating to events having an EventID of“demonstration”. The mobile operator may then configure the PCF 900 to trigger certain policies (e.g. prioritize premium users) and the NFVO 700 to trigger certain orchestration actions (e.g. deploy more resources) when a mass- event such as a demonstration occurs.
In step 901 , the CIP 300 determines information relating to the occurrence of an event. In this example, the CIP node 300 a user input from a Police department which has approved a legal demonstration. The CIP node 300 may therefore determine the following information:
Event-ID: demonstration
Timestamp: 21/06/2019
Location: area 1
In step 902, the NEF 310 receives the information from the CIP and may expose this information to the elements of the network that are subscribed to the Event-ID (for example the PCF 900 and the NFVO 700 in this case).
In step 903, the NFVO 700 receives the information from the NEF 310. The transmission of the information to the NFVO may therefore initiate a network adjustment. The NFVO 700 may then create more resources in area 1. For example, the NFVO may scale area 1 on the date 21/06/2019. This network adjustment may therefore compensate for the occurrence of the demonstration allowing for more resources to be available where lots of people will be present. In step 904, the PCF 900 receives the information from the NEF 310. The transmission of the information to the PCF 900 may therefore initiate a network adjustment. The PCF may provision Quality of Service policies to“Gold” level users thereby prioritising those users having mobile devices which are subscribed to a higher level of service in the network.
Figure 10 illustrates an example signalling diagram for a demonstration.
In this example, the NFVO 700 may transmit to the NEF the actions supported by NFVO for example, scale, migrate, etc. The PCF 900 may also transmit to the NEF 310 the actions supported by the PCF 900
In step 1001 , the CIP node 300 determines information relating to the occurrence of an event. In this example, the CIP node 300 a user input from a Police department which has approved a legal demonstration. The CIP node 300 may therefore determine the following information:
Event-ID: demonstration
Timestamp: 21/06/2019
Location: area 1
In step 1002, the NEF 310 receives the information from the CIP and may expose this information to the elements of the network.
In step 1003, the OSS 610, for example, using Intent Based Networking, may create one or more intents. In this example there are two intents:
Ί want to prioritize gold users if a demonstration occurs”; and
Ί want to have resources if a demonstration occurs”.
It will be appreciated that step 1003 may be performed at any time, and may be performed before step 1001.
The NEF 310 may then validate the intents. For example, the NEF 310 may compile the intents and translate into the following: Network Resource : NFVO.
Constraints: Area 1
Criteria : Demonstration
Instructions : migrate.
Network Resource : PCF
Constraints: Area 1
Criteria : Demonstration.
Instructions: prioritize gold users.
In step 1004, responsive to the event indicated in step 1002 being of the type of event indicated in the intent, the NEF 310 transmits instructions to perform a network adjustment to implement the intent in the network.
In this example therefore the NEF 310 transmits the instruction“migrate” to the NFVO 700 in step 1004, and the instruction“prioritize gold users” to the PCF 900 in step 1004.
The NFVO 700 and PCF 900 may then implement the instructions in the network to implement the network adjustments.
Figure 11 illustrates an example signalling diagram for a fire event.
In this example, the PCF 900 has subscribed to the NEF 310 to receive information relating to events having an EventID of “fire”. The mobile operator may then configure the PCF 900 to determine the subscribers in the area of the fire and alert them.
In step 1 101 , the CIP 300 determines information relating to the occurrence of an event. In this example, the CIP node 300 may receive an alarm from a fire brigade comprising information relating to the fire. The CIP node 300 may therefore determine the following information:
Event-ID: fire
Timestamp: 21/06/2019
Location: area 1 The CIP node 310 may then transmit the information to the NEF 310.
In step 1 102, the NEF 310 receives the information from the CIP node 310 and may expose this information to the elements of the network that are subscribed to the Event-ID (for example the PCF 900 in this case).
In step 1 103, the PCF 900 receives the information from the NEF 310. The transmission of the information to the PCF 900 may therefore initiate a network adjustment. The PCF 900 may then be configured by the mobile operator to ask the UDR 1 100 for identifications of subscribers that are near the Access Node where fire incident has happened.
In step 1 104, the PCF 900 may receive the list of subscribers from the UDR 1 100. The PCF 900 may decide to alert the subscribers as to the fire risk. For example, the PCF 900 may transmit, in step 1 105, an SMS or DoNAS indication to all subscribers in the area or, subscribers that have been in the area within a predetermined time, for example, within the last month
Figure 12 illustrates an example of a signalling diagram for a fire event.
In this example, the PCF 900 may transmit to the NEF 310 the actions supported by PCF for example,“notify” etc.
In step 1201 , the CIP node 300 determines information relating to the occurrence of an event. In this example, the CIP node 300 may receive an alarm from a fire brigade comprising information relating to a fire event. The CIP node 300 may therefore determine the following information:
Event-ID: fire
Timestamp: 21/06/2019
Location: area 1
In step 1202, the NEF 310 receives the information from the CIP node 300 and may expose this information to the elements of the network.
In step 1203, the OSS 610, for example, using Intent Based Networking, may create one or more intents. In this example, an intent in the following: “I want to notify to all users in the area if fire occurs”
It will be appreciated that step 1203 may be performed at any time, and may be performed before step 1201.
The NEF 310 may then validate the intent. For example, the NEF 310 may compile the intent and translate into the following:
Network Resource : PCF
Constraints: Area 1
Criteria : fire.
Instructions: Notify users in the area
In step 1204, responsive to the event indicated in step 1202 being of the type of event indicated in the intent, the NEF 310 transmits instructions to perform a network adjustment to implement the intent in the network.
In this example therefore the NEF 310 transmits the instruction“notify users in the area (area 1 )” to the PCF 900 in step 1204.
In step 1205, the PCF 900 retrieves from the UDR 1 100 the identification of subscribers in area 1.
In step 1206 the PCF 900 may decide to alert the subscribers as to the fire risk. For example, the PCF 900 may transmit a SMS or DoNAS indication to all subscribers in the area or, subscribers that have been in the area within a predetermined time, for example, within the last month. Figure 13 illustrates a context information provider (CIP) node 1300 comprising processing circuitry (or logic) 1301. The CIP node 1300 may be configured to perform the methods described with reference to CIP node 300 above. The processing circuitry 1301 controls the operation of the CIP node 1300 and can implement the method described herein in relation to an CIP node 1300. In particular the CIP may be configured to communicate with a core network, for example a 5G core network. In particular the CIP node 1300 may be configured to communicate with a Network Exposure Function in a service based architecture core network. The processing circuitry 1301 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the CIP node 1300 in the manner described herein. In particular implementations, the processing circuitry 1301 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the CIP node 1300.
Briefly, the processing circuitry 1301 of the CIP node 1300 is configured to: determine information relating to an event; and transmit the information to a Network Exposure Function, NEF, in the network.
In some embodiments, the CIP node 1300 may optionally comprise a communications interface 1302. The communications interface 1302 of the CIP node 1300 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 1302 of the CIP node 1300 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 1301 of CIP node 1300 may be configured to control the communications interface 1302 of the CIP node 1300 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. Optionally, the CIP node 1300 may comprise a memory 1303. In some embodiments, the memory 1303 of the CIP node 1300 can be configured to store program code that can be executed by the processing circuitry 1301 of the CIP node 1300 to perform the method described herein in relation to the CIP node 1300. Alternatively or in addition, the memory 1303 of the CIP node 1300, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 1301 of the CIP node 1300 may be configured to control the memory 1303 of the CIP node 1300 to store any requests, resources, information, data, signals, or similar that are described herein.
Figure 14 illustrates a Network Exposure Function (NEF) 1400 comprising processing circuitry (or logic) 1401. It will be appreciated that the NEF 1400 may comprise one or more virtual machines running different software and/or processes. The NEF 1400 may therefore comprise one or more servers, switches, storage devices and/or cloud computing infrastructure that run the software and/or processes.
The NEF 1400 may comprise the NEF 310 as described above. The processing circuitry 1401 controls the operation of the NEF 1400 and can implement the method described herein in relation to an NEF 1400. The processing circuitry 1401 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the NEF 1400 in the manner described herein. In particular implementations, the processing circuitry 1401 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the NEF 1400 or NEF 310.
Briefly, the processing circuitry 1401 of the NEF 1400 is configured to: receive information relating to an event from a context information provider node; and initiate a network adjustment responsive to the information relating to the event. In some embodiments, the NEF 1400 may optionally comprise a communications interface 1402. The communications interface 1402 of the NEF 1400 can be for use in communicating with other nodes, such as other virtual nodes or network functions. For example, the communications interface 1402 of the NEF 1400 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 1401 of NEF 1400 may be configured to control the communications interface 1402 of the NEF 1400 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
Optionally, the NEF 1400 may comprise a memory 1403. In some embodiments, the memory 1403 of the NEF 1400 can be configured to store program code that can be executed by the processing circuitry 1401 of the NEF 1400 to perform the method described herein in relation to the NEF 1400. Alternatively or in addition, the memory 1403 of the NEF 1400, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 1401 of the NEF 1400 may be configured to control the memory 1403 of the NEF 1400 to store any requests, resources, information, data, signals, or similar that are described herein.
Figure 15 illustrates a Network Function (NF) 1500 comprising processing circuitry (or logic) 1501. . It will be appreciated that the NF 1500 may comprise one or more virtual machines running different software and/or processes. The NF 1500 may therefore comprise one or more servers, switches, storage devices and/or cloud computing infrastructure that run the software and/or processes.
The NF 1500 may comprise any of the network functions above, for example, NF 500, NFVO 700 and PCF 900. The processing circuitry 1501 controls the operation of the NF 1500 and can implement the method described herein in relation to an NF 1500. The processing circuitry 1501 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the NF 1500 in the manner described herein. In particular implementations, the processing circuitry 1501 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the NF 1500. Briefly, the processing circuitry 1501 of the NF 1500 is configured to: receive information relating to an event from a network exposure function, wherein the event is of a first type; and initiate network adjustments corresponding to the first type, responsive to receiving the information relating to the event.
In some embodiments, the NF 1500 may optionally comprise a communications interface 1502. The communications interface 1502 of the NF 1500 can be for use in communicating with other nodes, such as other virtual nodes or network functions. For example, the communications interface 1502 of the NF 1500 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 1501 of NF 1500 may be configured to control the communications interface 1502 of the NF 1500 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
Optionally, the NF 1500 may comprise a memory 1503. In some embodiments, the memory 1503 of the NF 1500 can be configured to store program code that can be executed by the processing circuitry 1501 of the NF 1500 to perform the method described herein in relation to the NF 1500. Alternatively or in addition, the memory 1503 of the NF 1500, can be configured to store any requests, resources, information, data, signals, or similar that are described herein.
Figure 16 illustrates a Network Function (NF) 1600 comprising processing circuitry (or logic) 1601.
It will be appreciated that the NF 1600 may comprise one or more virtual machines running different software and/or processes. The NF 1600 may therefore comprise one or more servers, switches, storage devices and/or cloud computing infrastructure that run the software and/or processes. The NF 1600 may comprise the OSS 610 as described above. The processing circuitry 1601 controls the operation of the NF 1600 and can implement the method described herein in relation to an NF 1600. The processing circuitry 1601 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the NF 1600 in the manner described herein. In particular implementations, the processing circuitry 1601 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the NF 1600.
Briefly, the processing circuitry 1601 of the NF 1600 is configured to: transmit an indication of an intent associated with a type of event to a network exposure function.
In some embodiments, the NF 1600 may optionally comprise a communications interface 1602. The communications interface 1602 of the NF 1600 can be for use in communicating with other nodes, such as other virtual nodes or network functions. For example, the communications interface 1602 of the NF 1600 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 1601 of NF 1600 may be configured to control the communications interface 1602 of the NF 1600 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.
Optionally, the NF 1600 may comprise a memory 1603. In some embodiments, the memory 1603 of the NF 1600 can be configured to store program code that can be executed by the processing circuitry 1601 of the NF 1600 to perform the method described herein in relation to the NF 1600. Alternatively or in addition, the memory 1603 of the NF 1600, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 1601 of the NF 1600 may be configured to control the memory 1603 of the NF 1600 to store any requests, resources, information, data, signals, or similar that are described herein. It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim,“a” or“an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

1. A method, in a context information provider node, wherein the context information provider node is in communication with a network, the method comprising:
determining information relating to an event; and
transmitting the information to a Network Exposure Function, NEF, in the network.
2. The method as claimed in claim 1 wherein the information is transmitted over a T8 interface.
3. The method as claimed in any preceding claim wherein the step of determining comprises:
receiving an indication from one or more sensors indicating that the event has occurred or will occur.
4. The method as claimed in any preceding claim wherein the step of determining comprises:
receiving a user input indicating that the event has occurred or will occur.
5. The method as claimed in any preceding claim wherein the information comprises:
an indication of a type of event associated with the event.
6. The method as claimed in any preceding claim wherein the information comprises:
values of one or more parameters associated with the event.
7. The method as claimed in claim 6 wherein the one or more parameters comprise one or more of: a time stamp associated with the event, a location of the event, and estimated duration of the event.
8. The method as claimed in any preceding claim further comprising:
transmitting to the NEF an indication one or more types of event that the CIP is capable of reporting on; receiving, from the NEF, a subscription request indicating a subset of the one or more types of event; and
performing the step of transmitting the information to the NEF responsive to the event being of a type in the subset.
9. The method as claimed in claim 8 further comprising transmitting an indication of at least one parameter associated with each of the one or more types of event that the CIP is capable of providing information about.
10. The method as claimed in any one of claims 1 to 7 further comprising:
receiving an indication of one or more types of event; and performing the step of transmitting the information to the NEF responsive to the event being of a type in the one or more types of event.
1 1. A method performed by a Network Exposure Function, NEF, in a network wherein the method comprises:
receiving information relating to an event from a context information provider node in the network; and
initiating a network adjustment responsive to the information relating to the event.
12. The method as claimed in claim 1 1 wherein the network adjustment is configured to compensate for an effect of the event on the network.
13. The method as claimed in claim 1 1 or 12 wherein the step of initiating network adjustments comprises:
transmitting the information relating to the event to one or more network functions.
14. The method as claimed in claim 13 wherein the one or more network functions are subscribed to receive information about a type of event, wherein the event is of the type of event.
15. The method as claimed in claim 1 1 to 12 further comprising:
receiving an indication from a network function of an intent associated with a type of event.
16. The method as claimed in claim 15 wherein the step of initiating the network adjustment comprises:
responsive to the event being of the type of event, transmitting instructions to perform the network adjustment to implement the intent in the network.
17. A method in a network function in a network, the method comprising:
receiving information relating to an event from a network exposure function, wherein the event is of a first type; and
initiating network adjustments corresponding to the first type, responsive to receiving the information relating to the event.
18 .The method as claimed in claim 17 further comprising:
transmitting a subscription request to the network exposure function to subscribe to receive information relating to events of the first type.
19. A method in a network function in a network, the method comprising:
transmitting an indication of an intent associated with a type of event to a network exposure function.
20. A context information provider node, wherein the context information provider node is in communication with a network, the context information provider node comprising processing circuitry configured to:
determine information relating to an event; and
transmit the information to a Network Exposure Function, NEF, in the network.
21. The context information provider node as claimed in claim 20 wherein the information is transmitted over a T8 interface.
22. The context information provider node as claimed in any one of claims 20 to 21 wherein the processing circuitry is configured to perform the step of determining by:
receiving an indication from one or more sensors indicating that the event has occurred or will occur.
23. The context information provider node as claimed in any one of claims 20 to 22 wherein the processing circuitry is configured to perform the step of determining by:
receiving a user input indicating that the event has occurred or will occur.
24. The context information provider node as claimed in any one of claims 20 to 23 wherein the information comprises:
an indication of a type of event associated with the event.
25. The context information provider node as claimed in any one of claims 20 to 24 wherein the information comprises:
values of one or more parameters associated with the event.
26. The context information provider node as claimed in claim 26 wherein the one or more parameters comprise one or more of: a time stamp associated with the event, a location of the event, and estimated duration of the event.
27. The context information provider node as claimed in any one of claims 20 to 26 wherein the processing circuitry is further configured to:
transmit to the NEF an indication one or more types of event that the CIP is capable of reporting on;
receive, from the NEF, a subscription request indicating a subset of the one or more types of event; and
perform the step of transmitting the information to the NEF responsive to the event being of a type in the subset.
28. The context information provider node as claimed in claim 27 wherein the processing circuitry is further configured to transmit an indication of at least one parameter associated with each of the one or more types of event that the CIP is capable of providing information about.
29. The context information provider node as claimed in any one of claims 20 to 26 wherein the processing circuitry is further configured to:
receive an indication of one or more types of event; and perform the step of transmitting the information to the NEF responsive to the event being of a type in the one or more types of event.
30. A Network Exposure Function, NEF, in a network wherein the NEF comprises processing circuitry configured to:
receive information relating to an event from a context information provider node in the network; and
initiate a network adjustment responsive to the information relating to the event.
31. The NEF as claimed in claim 30 wherein the network adjustment is configured to compensate for an effect of the event on the network.
32. The NEF as claimed in claim 30 or 31 wherein the processing circuitry is configured to perform the step of initiating network adjustments by:
transmitting the information relating to the event to one or more network functions.
33. The NEF as claimed in claim 32 wherein the one or more network functions are subscribed to receive information about a type of event, wherein the event is of the type of event.
34. The NEF as claimed in claim 30 to 31 wherein the processing circuitry is further configured to:
receive an indication from a network function of an intent associated with a type of event.
35. The NEF as claimed in claim 34 wherein the processing circuitry is configured to perform the step of initiating the network adjustment by:
responsive to the event being of the type of event, transmitting instructions to perform the network adjustment to implement the intent in the network.
36. A network function in a network, the network function comprising processing circuitry configured to:
receive information relating to an event from a network exposure function, wherein the event is of a first type; and
initiate network adjustments corresponding to the first type, responsive to receiving the information relating to the event.
37. The network function as claimed in claim 38 wherein the processing circuitry is further configured to:
transmit a subscription request to the network exposure function to subscribe to receive information relating to events of the first type.
38. A network function in a network, the network function comprising processing circuitry configured to:
transmitting an indication of an intent associated with a type of event to a network exposure function.
PCT/EP2019/072532 2019-07-05 2019-08-22 Methods and apparatus for providing context information to a network WO2021004644A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP19382576 2019-07-05
EP19382576.7 2019-07-05

Publications (1)

Publication Number Publication Date
WO2021004644A1 true WO2021004644A1 (en) 2021-01-14

Family

ID=67253838

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2019/072532 WO2021004644A1 (en) 2019-07-05 2019-08-22 Methods and apparatus for providing context information to a network

Country Status (1)

Country Link
WO (1) WO2021004644A1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070283005A1 (en) * 2006-06-06 2007-12-06 Beliles Robert P Dynamically responding to non-network events at a network device in a computer network
US20160127943A1 (en) * 2014-10-31 2016-05-05 At&T Intellectual Property I, L.P. Event-driven network demand finder of a radio access network
WO2019104357A1 (en) * 2017-11-27 2019-05-31 Cisco Technology, Inc. Subscription-based event notification techniques for reducing data buffering in mobile networks

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070283005A1 (en) * 2006-06-06 2007-12-06 Beliles Robert P Dynamically responding to non-network events at a network device in a computer network
US20160127943A1 (en) * 2014-10-31 2016-05-05 At&T Intellectual Property I, L.P. Event-driven network demand finder of a radio access network
WO2019104357A1 (en) * 2017-11-27 2019-05-31 Cisco Technology, Inc. Subscription-based event notification techniques for reducing data buffering in mobile networks

Similar Documents

Publication Publication Date Title
US11816504B2 (en) Serverless computing architecture
US11677715B2 (en) Methods of and systems of service capabilities exposure function (SCEF) based internet-of-things (IOT) communications
US11601555B2 (en) Methods and apparatuses for service layer charging correlation with underlying networks
AU2019251152B2 (en) Method and device for subscribing to service
US11825319B2 (en) Systems and methods for monitoring performance in distributed edge computing networks
US11877177B2 (en) Systems and methods for providing edge-based quality of service orchestration for multi-access edge computing (MEC) in a network
KR20130116913A (en) System and method for communicating data between an application server and an m2m device
EP3742812B1 (en) Device, system, and method for customizing user-defined mobile network
US11855864B2 (en) Method and apparatus for collecting network traffic in wireless communication system
US20210176366A1 (en) Methods, apparatus and computer-readable mediums supporting subscriptions to events in a core network
US20220225223A1 (en) Systems and methods for exposing network slices for third party applications
US20220312159A1 (en) System and method for determining data usage in a converged charging system
US11871339B2 (en) Filters for bulk subscriptions
WO2021004644A1 (en) Methods and apparatus for providing context information to a network
KR102244539B1 (en) Method and apparatus for acquiring location information of user equipment based on radio unit
WO2023274569A1 (en) Obtaining information relating to tethering events
US20220060397A1 (en) Methods and apparatus for user plane function analytics
CN117221841A (en) Flow charging system and method
WO2024037705A1 (en) Sending and receiving a network slice service profile

Legal Events

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

Ref document number: 19755926

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 19755926

Country of ref document: EP

Kind code of ref document: A1