DEVICE AND METHOD FOR EXPOSURE INFORMATION BASED ADAPTATION OF A NETWORK AND/OR MANAGEMENT FUNCTION TECHNICAL FIELD

The present invention relates to the field of mobile communication and in particular to vehicle to anything (V2X) communication. More specifically, the present invention relates to adapting a network function and/or a management function based on exposure information that relates to properties of mobile communication.

BACKGROUND

The next generation of mobile and wireless communications, namely, the fifth generation (5G) envisions new use cases, services and applications, such as enhanced mobile broadband (eMBB), ultra-reliable low latency communications (URLLC), and massive machine-type communications (mMTC). Any combinations of these use cases can also be possible, such as ultra-reliable communications, low-latency communications, or low-latency eMBB communications. Among these, enhanced Vehicular to everything (eV2X) can be seen as special 5G service type, which includes both safety and non-safety services, according to TS 22.186. One of the key requirements for an eV2X service is critical latency (3- 10ms) and reliability (99.999% and higher) KPIs, which may need to be adapted on demand, due to new application requests (e.g. a Level of Automation change, dynamic group-UE formations) or network changes (network congestion to core network and/or access network entities, mode of transmission / operation change). eV2X can be seen as special 5G service type which may require different network monitoring and control by a vertical customer (e.g. an OEM) and/or different network parameterization for supporting different services or variants of the same service, due to the following factors:

- A V2X service may include either fully localized (direct, indirect V2V) and/or non- localized (V2N/V2I) traffic, or both. - Different transmission modes (unicast, multicast broadcast) are envisioned and can flexibly adapt to meet the vertical customers’ requirements.

- Different mode of operation or integration (Uu, PC5) by switching-/diversity techniques can be used either for service continuity or for mobility or for optimization purposes.

- Different levels of vehicle automation (LoA 1 to 5) of a V2X service will shape the network QoS requirements.

Two key issues may emerge for eV2X communications:

Issue 1: Dynamic interaction between Application (V2X-UE, V2X Server) and 5G System (e.g. for predictive QoS, UP management, LoA change) requires enhanced exposure of network capabilities by the V2X Application which can be different per V2X service. The level of exposure can be seen as a service which can be offered to a 3rd party. However, the control plane does not support the flexible configuration and adaptation of the level of exposure for a service. If a service operation changes, the network will most probably terminate the session and will try to establish a new one with a different exposure level. This may be critical for URLLC/V2X services.

Issue 2: Network exposure and in particular the exposure of network control functionalities is something“precious” for an operator and if it is agreed to give some extra capabilities to some particular services/slices, 3rd-party/vertical online charging needs to be triggered, according to the level of exposure of control traffic to UEs. However, there is no vertical charging model which dynamically captures service operation changes as mentioned above.

Therefore, the need arises how to enable online charging of a vertical user based on an agreed exposure level and for usage of control plane traffic by a 3rd party for an ongoing V2X session.

In 4G (TS32.254), northbound API online charging is performed by the SCEF using the common Ro based Credit-Control application specified in TS 32.299. In order to provide the data required for the management activities outlined in TS 32.240, the SCEF shall be able to perform online charging for 1) charging data related to northbound API invocation; and 2) charging data related to northbound API notification. In this, SCEF collects some charging information and translates it to billing requests. However, this does not refer to vertical charging.

In 5GS, the Monitoring Events feature is intended for monitoring of specific events in a 3GPP system and making such monitoring events information reported via a network exposure function (NEF) to an application function (AF). The AF can be an application server or an application function residing at a vertical domain. It comprises means that allow NFs in 5GS for configuring specific events, the event detection, and the event reporting to the requested party. Depending on the specific monitoring event or information, it is either an AMF or an UDM that is aware of the monitoring event or information and makes it reported via the NEF [TS23.502, section 4.15.3.1]. NEF also supports the exposure of session stats regarding mobility stats (AMF-NEF-AF), policy stats (PCF-NEF-AF) and session stats (SMF-NEF-AF) [TS23.502, section 4.15.5]

According to TR23.899, one of the potential charging requirements that should be supported for network capability exposure is charging based on the network capability invocation or subscription for the network capabilities exposure. A solution is proposed for offline/online charging considering the authentication by an NEF and the interaction with a billing domain. However, this is triggered by an application request, without mentioning levels of exposure and also without considering actual control traffic which is exposed.

That is, in the prior art there is no solution for online charging of a vertical user based on an exposure level. Also, there is a need for usage of control plane traffic by a 3rd party for an ongoing V2X session.

SUMMARY

In view of the above-mentioned problems and disadvantages, the present invention aims to improve the prior art solutions. In general, the object of the present invention is to allow for logging of control traffic and notification of an NEF about an adaptation of exposure. More specifically, the present invention gives a definition and mapping of different capability exposure levels to eV2X services / scenarios by 5G CP. Also, the configuration / adaptation of Exposure-on-Demand during the operation of a V2X Service and the impact on charging is addressed. Also, the present invention allows for authorization and adaptation of billing for a session; and for logging of actual control traffic to be exposed to AF and for charging a vertical user accordingly.

The objective of the present invention is achieved by the solution provided in the enclosed independent claims. Advantageous implementations of the present invention are further defined in the dependent claims.

In other words, the present invention solves the problem of controlling the control traffic to be exposed to a 3rd party, and thereby allows for the charging domain to dynamically adapt online billing of a vertical user based on a configuration/adaption of an exposure level - without disrupting a V2X service. Without this solution, a negotiation between the vertical user and an MNO, as well as authorization and credit control, would take much time, which might be critical for the V2X service continuity. This is even more critical when the vehicles involved in a V2X service, belong to different operators; hence the vertical charging may involve multiple stakeholders.

In more detail, the present invention introduces a functionality, which is logging the control traffic to be exposed to the 3rd party and based on the level of exposure required for a service, to trigger charging/billing of a vertical customer.

The concept of the present invention basically comprises three steps:

Step 1: Receiving a set of exposure levels which may be either sent by Network Operation, Administration and Maintenance (OAM) and/or by an application request (e.g. by an application server) to indicate, what exposure is provided from network functions to an AF via NEF and is mapped to one or more V2X services or modes of V2X services.

These exposure levels can be at least some of the following: Capability of AF to monitor network events; Capability of AF to monitor network/interface stats; Capability of AF to monitor real-time domain/sub-net monitoring events (e.g. RAN, wireless TN); Capability of AF to monitor sidelink conditions (PC5 monitoring); Capability of AF to influence traffic routing; Capability of AF to monitor per user QoS; Capability of AF to influence QoS; Capability of AF to perform pro-active/re-active QoS management (monitoring, configuration, adaptation); Capability of AF to perform UP configuration adaptation (e.g. select transmission mode); Capability of AF to monitor UE/group-UE channel conditions and perform pro-active/re-active unicast/ multicast resource management (RRM/RRC); Capability of AF to Monitor Slice Congestion levels; Capability of AF to Select Slices / Influence Slice Selection.

Step 2: Based on the obtained mapping of V2X services to exposure levels, the present invention allows for logging control traffic, which is exposed via NEF to AF for PDU sessions which are associated with the vertical customer (e.g. this can be captured by network slice information of the PDU session).

Step 3: The functionality, based on the control traffic charging policies (e.g. based on volume, criticality, exposure of network infrastructure) may trigger the charging adaptation of the vertical user based on actual control plane exposure.

Again in other words, a general aspect of the present invention is to provide a network device (which may be co-located with the exposure functionality), which:

- obtains network capabilities to be exposed to a vertical customer for a given V2X service and/or a V2X service operation, according to an SEA, using a dynamic configuration/mapping table from a management system and/or by application requests,

- logs Control Traffic, which is exposed by any network function or a particular network sub-net (e.g. RAN, TN) to an AF, with granularity per PDU session or flow, based on the mapping table and/or AF/V2X service requests, and

- translates the exposure of per session control traffic to a per- vertical customer’s exposure demand and triggers online charging/billing of the vertical customer (e.g. a vehicle manufacturer) based on the control traffic that is exposed or expected to be exposed. A first aspect of the present invention provides a network device configured to: obtain a control information based on an exposure information; and trigger an adaptation of a network and/or management function based on the control information.

In particular, the obtaining the control information comprises storing or logging the control information in a memory or database.

In an implementation form of the first aspect, the exposure information is obtained from another device and/or is predetermined.

In particular, obtaining the exposure information from another device comprises receiving the exposure information from another device or fetching the exposure information from another device.

In a further implementation form of the first aspect, the adaptation of the network and/or management function comprises an adaptation of a billing and/or charging function.

In particular, the network device may be located in a CN-C entity, and/or an NEF, and/or a RAN.

In particular, the control traffic can be control plane traffic.

In a further implementation form of the first aspect, the exposure information comprises an information related to a vehicle to anything, V2X, service and/or a V2X service mode and in particular a mapping of this information to an exposed capability of a network function, NF.

In particular, the V2X service mode can comprise at least one of the following:

- a level of automation;

- mode of operation (uplink, downlink, sidelink);

- access technology associated to a V2X service.

In a further implementation form of the first aspect, the exposure information further comprises at least one of the following parameters: - Service ID

- NSSAI

- LCU ID

- Exposure level of an NF to be exposed

- Time validity and/or periodicity

- Geographical Area, e.g. a RSU-level, a cell-level, or a TA level.

In a further implementation form of the first aspect, the control information comprises an exposure of a NF to an application function, AF.

In a further implementation form of the first aspect, the control information comprises a control traffic report from the NF.

In a further implementation form of the first aspect, the control traffic report comprises at least one of the following parameters:

- Service ID

- Device ID

- User ID / or Group-UE IDs and/or PDU Session ID(s)

- Exposed Control traffic parameters:

- Volume

- Criticality,

- Time validity and/or periodicity

- Geographical Area, e.g. RSU-level, cell-level, TA level.

In a further implementation form of the first aspect, the network device is further configured to configured to obtain the control information per PDU session and/or per traffic flow.

In a further implementation form of the first aspect, the network device is further configured to adapt the network and/or management function based on an exposure demand information, in particular based on the control information, and wherein the exposure demand information includes at least one of the following parameters:

- Service ID, - NSSAI,

- Exposed Control traffic parameters per vertical customer:

- Billing estimation,

- Volume,

- Criticality,

- Time validity and/or periodicity,

- Geographical Area, e.g. RSU-level, cell-level, TA level.

In a further implementation form of the first aspect, the network device is further configured to adapt the network and/or management function based on an adaptation of a vehicle-to-vehicle, V2V, communication mode.

In particular, the V2V communication mode can be a direct V2V communication mode, or an indirect V2V communication mode.

In a further implementation form of the first aspect, the network device is further configured to adapt the obtaining of the control information based on an application request and/or based on a network request.

In a further implementation form of the first aspect, the network device is further configured to adapt the obtaining of the control information based on a change of a V2V session.

In a further implementation form of the first aspect, the a change of the V2V session is a change of a level of automation, LoA, in particular caused by a V2X server.

In a further implementation form of the first aspect, the network device is further configured to adapt the obtaining of the control information based on a change of network slice instances, NSIs, associated with a V2V session.

In a further implementation form of the first aspect, the network device is further configured to trigger the adaptation of the network and/or management function periodically or upon request. A second aspect of the present invention provides a method for operating a network device, the method comprising the steps of: obtaining, by the network device, a control information based on an exposure information; and triggering, by the network device, an adaptation of a network and/or management function based on the control information.

In particular, the obtaining the control information comprises storing or logging the control information in a memory or database.

In an implementation form of the second aspect, the exposure information is obtained from another device and/or is predetermined.

In particular, obtaining the exposure information from another device comprises receiving the exposure information from another device or fetching the exposure information from another device.

In a further implementation form of the second aspect, the adaptation of the network and/or management function comprises an adaptation of a billing and/or charging function.

In particular, the method may be performed in a CN-C entity, and/or an NEF, and/or a RAN.

In particular, the control traffic can be control plane traffic.

In a further implementation form of the second aspect, the exposure information comprises an information related to a vehicle to anything, V2X, service and/or a V2X service mode and in particular a mapping of this information to an exposed capability of a network function, NF.

In particular, the V2X service mode can comprise at least one of the following:

- a level of automation;

- mode of operation (uplink, downlink, sidelink); - access technology associated to a V2X service.

In a further implementation form of the second aspect, the exposure information further comprises at least one of the following parameters:

- Service ID

- NSSAI

- LCU ID

- Exposure level of an NF to be exposed

- Time validity and/or periodicity

- Geographical Area, e.g. a RSU-level, a cell-level, or a TA level.

In a further implementation form of the second aspect, the control information comprises an exposure of a NF to an application function, AF.

In a further implementation form of the second aspect, the control information comprises a control traffic report from the NF.

In a further implementation form of the second aspect, the control traffic report comprises at least one of the following parameters:

- Service ID

- Device ID

- User ID / or Group-UE IDs and/or PDU Session ID(s)

- Exposed Control traffic parameters:

- Volume

- Criticality,

- Time validity and/or periodicity

- Geographical Area, e.g. RSU-level, cell-level, TA level.

In a further implementation form of the second aspect, the method further includes obtaining, by the network device, the control information per PDU session and/or per traffic flow.

In a further implementation form of the second aspect, the method further includes adapting, by the network device, the network and/or management function based on an exposure demand information, in particular based on the control information, and the exposure demand information includes at least one of the following parameters:

- Service ID,

- NSSAI,

- Exposed Control traffic parameters per vertical customer:

- Billing estimation,

- Volume,

- Criticality,

- Time validity and/or periodicity,

- Geographical Area, e.g. RSU-level, cell-level, TA level.

In a further implementation form of the second aspect, the method further includes adapting, by the network device, the network and/or management function based on an adaptation of a vehicle-to-vehicle, V2V, communication mode.

In particular, the V2V communication mode can be a direct V2V communication mode, or an indirect V2V communication mode.

In a further implementation form of the second aspect, the method further includes adapting, by the network device, the obtaining of the control information based on an application request and/or based on a network request.

In a further implementation form of the second aspect, the method further includes adapting, by the network device, the obtaining of the control information based on a change of a V2V session.

In a further implementation form of the second aspect, the a change of the V2V session is a change of a level of automation, LoA, in particular caused by a V2X server.

In a further implementation form of the second aspect, the method further includes adapting, by the network device, the obtaining of the control information based on a change of network slice instances, NSIs, associated with a V2V session. In a further implementation form of the second aspect, the method further includes triggering, by the network device, the adaptation of the network and/or management function periodically or upon request. The second aspect and its implementation forms include the same advantages as the first aspect and its respective implementation forms.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF DRAWINGS

The above-described aspects and implementation forms of the present invention will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

FIG. 1 shows a schematic view of network device according to an embodiment of the present invention.

FIG. 2 shows a schematic view of an operating example according to the present invention.

FIG. 3 shows another schematic view of an operating example according to the present invention. FIG. 4 shows another schematic view of an operating example according to the present invention.

FIG. 5 shows another schematic view of an operating example according to the present invention.

FIG. 6 shows a schematic view of a method according to an embodiment of the present invention. DETAILED DESCRIPTION OF EMBODIMENTS

FIG. 1 shows a network device 100 according to an embodiment of the present invention. The network device 100 is configured to obtain a control information 101 based on an exposure information 102. Obtaining the control information 101 optionally may include that the control information 101 is pre-stored in the network device 100, or determined by the network device 100, or received from another network device 100. Once the control information 101 is obtained, the network device 100 is further configured to trigger an adaptation of a network and/or management function based on the control information 101.

FIG. 2 shows a more detailed description of the operation of the network device 100. In the following description in view of FIG. 2 to FIG. 5, the network device 100 is also called Logical Control Unit (LCU). As shown in FIG. 2, initially, an AF / service request is sent from the AF to the LCU, which includes the exposure level (i.e. the exposure information 102) for a V2X service or alternatively this is received by OAM which maps the service to a required Exposure based on pre-configured mapping tables (how the mapping tables are configured is out- of-scope of this invention).

Then, the LCU sends a logging subscription request to the involved entities (e.g. monitoring request from NWDAF, RAN and other NFs) and receives an ACK/NACK. In the following, the LCU either acquires exposed control traffic usage reports (i.e. the control information 101) from NEF (if no co-located with NEF); or calculates the exposed control traffic that passes through NEF (if co-located with or part of NEF) per session or flow.

Based on the usage, the LCU translates the per session report/calculations to per vertical customer (or V2X service) exposure and usage requirement.

Then, the LCU sends a logging report of the exposed control traffic to the charging domain, either periodically or by a trigger from LCU (or by request from Charging domain), in order to update the billing of the vertical user based on the new requirement.

In turn, the charging domain and the vertical customer agree on the new charging based on the updated exposure requirement. That is, the adaptation of the network and/or management function optionally comprises an adaptation of a billing and/or charging function 201.

To implement the function as shown in FIG. 2, the present invention makes use of the following new messages:

Service-to-Exposure level mapping message (OAM to LCU):

This information e.g. is or is included in the exposure information 102 and may be sent by an OAM to the LCU, to set the exposure level per V2X service (or mode of service) based on an SLA agreement between a vertical customer and an operator. This may include at least one of the following parameters:

- Service ID

- NSSAI

- LCU ID

- Exposure level <NFs to be exposed>

- Time validity and/or periodicity

- Geographical Area (RSU-level, cell-level, TA level, etc.) Control Plane (CP) Traffic Logging report (involved NF to LCU):

This report e.g. is or is included in the control information 101, and is sent by the NF which exposes control information to a 3rd party (AF), to the LCU, to allow LCU to store and calculate the usage over time per vertical customer. This may include at least one of the following parameters:

- Service ID, LCU ID

- User ID / or Group-UE IDs and/or PDU Session ID(s)

- Exposed Control Traffic parameters:

- Volume

- Criticality,

- Time validity and/or periodicity

- Geographical Area (RSU-level, cell-level, TA level, etc.)

Exposure logging reporting/trigger (LCU to Vertical Charging Domain/OAM):

This message is sent after the processing by the LCU and the translation to per- vertical/slice reporting to be used for the Charging Domain and/or OAM. This may be either triggered by LCU or may be periodically reported to charging domain. This may include at least one of the following parameters:

- Service ID,

- NSSAI,

- Exposed Control Traffic parameters per vertical:

- Billing estimation,

- Volume,

- Criticality,

- Time validity and/or periodicity

- Geographical Area (RSU-level, cell-level, TA level, etc.)

In view of FIG. 3 and FIG. 4, an embodiment which includes a change between direct and in-direct V2V communication is discussed below:

This embodiment describes a case of having network-assisted V2V communication (e.g. platooning). In this case, two modes of operation may be provided: - Direct V2V: In this option, user-plane (UP) traffic passes via sidelink; whereas the Control Plane (CP) traffic may be handled by the network (RAN, CN). The exposure required in this case would be about monitoring very abstract (e.g. PC5 monitoring, active UE density, abstract network status information reporting by NWDAF), since the reliance on network is mainly for scheduling and charging.

-In-direct V2V: In this option the CP and UP are both handled by the network. The required exposure may be more detailed, e.g. Uu monitoring, RAN resource usage monitoring, AF to influence QoS, AF to provide UP path configuration etc.

However, this exposure may not be fixed, since the AF may need to have further information on some particular network parameters in order to identify whether to request network changes (change of mode of operation) or application changes (e.g. formation of vehicles). Two scenarios are shown as examples:

- Application-triggered: Initially, a direct V2V service initiated. AF needs to further monitor the Uu condition, since it estimates that the formation of the vehicles is about to change. ECU, based on a new application request, requires that the NFs that will expose their service to AF to be activated and send CP Traffic Fogging report to ECU. In the following, ECU interacts with the charging domain using Exposure logging reporting/trigger msg to adapt the vertical charging. This concept is e.g. shown in FIG. 3.

- Network-triggered: Initially, a direct V2V service initiated. Network wants to change from direct to in-direct V2V due to expected PC5 QoS downgrade. This changes the exposure level; however this is not captured by the Service-to-Exposure level mapping message. Hence, the ECU captures the adaptation of the exposure via the CP Traffic Fogging report by the involved NFs. Following, ECU interacts with the charging domain using Exposure logging reporting/trigger msg to adapt the vertical charging. This concept is e.g. shown in FIG. 4.

In the following optional embodiment, a change of a level of automation (FoA) by an application is disclosed. In this embodiment, a V2X server decides to change the FoA for a particular V2V ongoing session. This may require additional exposure of capabilities to AF (e.g. capability to influence QoS). Based on the updated configuration, LCU requires that the NFs that will expose their service to AF to be activated and send Control Plane (CP) Traffic Logging report to LCU. Following, LCU interacts with the charging domain using Exposure logging reporting/trigger msg to adapt the vertical charging.

In view of FIG. 5, an embodiment including slice adaptation for V2X is disclosed.

The network requires re-selection of a Network Slice Instance (NSI) which is associated to a V2X session 501 (e.g. based on monitoring of slice congestion by NWDAF). In this case, the configuration of CP and UP functions will change. Also, this may change the exposure capabilities which are offered to the vertical user, since the exposure is part of the NSI configuration (by OAM).

An example is shown in FIG. 5. In this example, NSI x is configured by OAM for exposing network monitoring stats and NSI y is configured by OAM for exposing monitoring analytics by RAN and NWDAF.

The LCU may not be aware of the NSI adaptation. However, by logging the new control traffic to be exposed, it calculates the vertical charging requirement and triggers a reporting to the charging domain as in previous cases.

FIG. 6 shows a method 600 according to an embodiment of the present invention. The method 600 corresponds to network device 100. The method 900 comprises a steps of obtaining 601, by a network device 100, a control information 101 based on an exposure information 102. The method 600 comprises a second step of triggering 602, by the network device 100, an adaptation of a network and/or management function based on the control information 102.

The present invention has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word“comprising” does not exclude other elements or steps and the indefinite article“a” or“an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.