Charging report method and core network equipment

Abstract

A charging reporting method performed by a session management function (SMF) and a charging function (CHF). The SMF and CHF may be implemented in a first core network device and a second core network device. The first core network device sends a request for a support feature. The second core network device receives a request for a support feature, the request to confirm whether the CHF in the core network supports the support feature, where the support feature includes a Converged Charging Service (CCS) for an Environmental Internet of Things (AIoT) traffic type. The CHF determines whether the CHF supports the support feature, and when the CHF supports the support feature, sends a response to the request, the response indicating that the CHF supports the support feature of the CCS, where the response enables signaling of protocol data unit (PDU) session charging information for the CCS of the AIoT.

Description

[0001] BACKGROUND TECHNICAL FIELD

[0002] The present disclosure relates to the field of communication systems, and in particular to a charging reporting method, a terminal device and a base station. BACKGROUND

[0003] Related Art

[0004] Wireless communication systems such as those defined by third-generation (3G) mobile telephone standards and technologies are well known. Such 3G standards and technologies have been developed by the Third Generation Partnership Project (3GPP). Third generation wireless communication is generally developed to support macro cell mobile telephone communications. The communication systems and networks have evolved towards broadband and mobile systems. In cellular wireless communication systems, user equipment (UE) is connected to a radio access network (RAN) over a wireless link. The RAN comprises a set of base stations (BS) which provide the wireless link to UEs located in cells covered by the base stations and an interface to a core network (CN) which provides overall network control. It will be appreciated that the RAN and CN each perform respective functions related to the overall network. The Third Generation Partnership Project has developed a so-called Long Term Evolution (LTE) system for mobile access networks, namely the Evolved Universal Mobile Telecommunication System Territorial Radio Access Network (E-UTRAN), in which one or more macro cells are supported by base stations known as eNodeBs or eNBs. More recently, LTE has evolved towards so-called 5G or NR (New Radio) systems in which one or more cells are supported by base stations known as gNBs.

[0005] Technical Problem

[0006] The environmental Internet of Things (IoT) (‘environmental’ and ‘Internet of Things’) is a concept originally proposed by 3GPP to refer to an ecosystem with a large number of objects in the technology industry, in which each item is connected to a wireless sensor network using a low-cost self-powered sensor node.

[0007] A billing mechanism for Ambient IoT (AIoT) has not been developed yet. Therefore, a method of transmitting billing information is needed. SUMMARY

[0008] An object of the present disclosure is to propose a charging reporting method and a core network device.

[0009] In a first aspect, embodiments of the present invention provide a charging reporting method performed by a first core network device, the method comprising:

[0010] transmitting a request for a support feature to confirm whether a charging function (CHF) in a core network supports the support feature, wherein the support feature comprises a converged charging service (CCS) for an Ambient IoT (AIoT) service type; and

[0011] performing signaling of protocol data unit (PDU) session charging information of the CCS for the AIoT when a response to the request is received, the response indicating that the CHF supports the support feature of the CCS.

[0012] In a second aspect, embodiments of the present invention provide a first core network device comprising a processor configured to invoke and run a computer program stored in a memory to cause a device having a chip installed therein to perform the disclosed method and any combination of multiple embodiments of the disclosed method.

[0013] In a third aspect, embodiments of the present invention provide a charging reporting method performed by a second core network device, the method comprising:

[0014] receiving a request for a support feature to determine whether a charging function (CHF) in a core network supports the support feature, wherein the support feature comprises a converged charging service (CCS) for an Ambient IoT (AIoT) service type;

[0015] determining whether the CHF supports the support feature; and

[0016] transmitting a response to the request when the CHF supports the support feature, the response indicating that the CHF supports the support feature of the CCS, wherein the response enables signaling of protocol data unit (PDU) session charging information of the CCS for the AIoT.

[0017] In a fourth aspect, embodiments of the present invention provide a second core network device including a processor configured to invoke and run a computer program stored in a memory, such that a device in which a chip is mounted performs the disclosed methods and any combination of several embodiments of the disclosed methods.

[0018] In a fourth aspect, embodiments of the present invention provide a base station including a processor configured to invoke and run a computer program stored in a memory, such that a device in which the processor is installed performs the disclosed method.

[0019] The disclosed methods can be programmed as computer-executable instructions stored in a non-transitory computer-readable medium. When loaded into a computer, the non-transitory computer-readable medium instructs the computer's processor to execute the disclosed methods.

[0020] Non-transitory computer-readable media may include at least one of the following: hard disk; compact optical disc read-only memory (CD-ROM); optical storage device; magnetic storage device; read-only memory; programmable read-only memory; erasable programmable read-only memory; electrically programmable read-only memory (EPROM); electrically erasable programmable read-only memory; and flash memory.

[0021] The disclosed methods can be programmed into a computer program product that causes a computer to perform the disclosed methods.

[0022] The disclosed methods can be programmed into a computer program that causes a computer to execute the disclosed methods.

[0023] Beneficial effects

[0024] For any new service in 3GPP, billing reporting is required from the core network 5GS / 5GC to the Billing Function (CHF). This is crucial for enabling billing of specific services within the service provider's billing domain and ultimately monetizing those services, thus achieving a return on investment (ROI) when deploying them. This also applies to the Internet of Things (IoT) in the environment. This invention defines how billing reporting will be applied to the IoT in the environment and defines the corresponding parameters required for such billing reporting.

[0025] Once the billing mechanisms and billing information for AIoT are established, they can facilitate the commercialization and investment in AIoT. Attached Figure Description

[0026] To more clearly illustrate the embodiments of this disclosure or related technologies, the following drawings, which will be briefly described in various embodiments, are provided. Obviously, the drawings are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings from these drawings without any inventive effort.

[0027] Figure 1 A schematic diagram illustrating a wireless communication system including user equipment (UE), base stations, and network entities is shown.

[0028] Figure 2 A schematic diagram of the display service and application server is shown.

[0029] Figure 3 A schematic diagram illustrating an embodiment of the disclosed method is shown.

[0030] Figure 4 A schematic diagram illustrating the billing interface is shown.

[0031] Figure 5 A schematic diagram is shown illustrating a session management function (SMF) with a charging trigger function (CTF).

[0032] Figures 6 to 9 A schematic diagram illustrating an example of the AIoT session establishment process is shown.

[0033] Figure 10 A schematic diagram illustrating an example of the core network system of this disclosure is shown.

[0034] Figure 11 A schematic diagram illustrating a wireless communication system according to an embodiment of the present disclosure is shown. Detailed Implementation

[0035] The technical content, structural features, objectives, and effects of the embodiments of this disclosure are described in detail below with reference to the accompanying drawings. Specifically, the terminology used in the embodiments of this disclosure is for the purpose of describing specific embodiments only and is not intended to limit this disclosure.

[0036] The following is a list of abbreviations used in the instruction manual:

[0037] Table 1

[0038]

[0039]

[0040] The environmental IoT system and architecture requirements study will be implemented in version 19 of 3GPP SA WG2 (Services for Systems Architecture Working Group). Once the architecture is complete, the billing reporting solution will also be defined in 3GPP SA WG5. Billing reporting from the core network SMF to the billing function (CHF) is crucial for service providers' environmental IoT monetization. This invention defines how environmental IoT billing reporting should work.

[0041] refer to Figure 1 The telecommunications system, including UE 10a, UE 10b, base station (BS) 20a and network entity equipment 30, performs the method disclosed according to embodiments of the present disclosure. Figure 1 This is for illustrative purposes only and not as a limitation, and the system may include more UE, BS, and CN entities. Connections between devices and device components are shown as lines and arrows in the diagram. UE 10a may include processor 11a, memory 12a, and transceiver 13a. UE 10b may include processor 11b, memory 12b, and transceiver 13b. Base station 20a may include processor 21a, memory 22a, and transceiver 23a. Network entity device 30 may include processor 31, memory 32, and transceiver 33. Each of processors 11a, 11b, 21a, and 31 may be configured to implement the functions, procedures, and / or methods described in the specification. The radio interface protocol layer may be implemented in processors 11a, 11b, 21a, and 31. Each of memories 12a, 12b, 22a, and 32 may operatively store various programs and information to operate the connected processor. Each of transceivers 13a, 13b, 23a, and 33 is operatively coupled to the connected processor and transmits and / or receives radio or wired signals. UE 10a can communicate with UE 10b via a side link. Base station 20a can be an eNB, gNB, or one of several other types of radio nodes and can configure radio resources for UE 10a and UE 10b.

[0042] Network entity device 30 can be a node in the CN. The CN can include an LTE CN or a 5G core (5GC). The LTE CN or 5G core (5GC) includes User Plane Function (UPF), Session Management Function (SMF), Access and Mobility Management Function (AMF), Unified Data Management (UDM), Policy Control Function (PCF), Control Plane (CP) / User Plane (UP) Separation (CUPS), Authentication Server (AUSF), Network Slice Selection Function (NSSF), and Network Exposure Function (NEF).

[0043] Examples of UEs in the specification may include either UE 10a or UE 10b. Examples of base stations in the specification may include base station 20a. Uplink (UL) transmission of control signals or data may be a transmission operation from the UE to the base station. Downlink (DL) transmission of control signals or data may be a transmission operation from the base station to the UE. DL control signals may include downlink control information (DCI) or radio resource control (RRC) signals from the base station to the UE.

[0044] At least some of the multiple UEs in a telecommunications system may be zero-power devices requiring an Ambient Internet of Things (AIoT) service type (or service category). The UE may initiate service establishment, such as an AIoT session establishment procedure or a PDU session establishment procedure for creating a Protocol Data Unit (PDU) session. For example, the UE initiates an AIoT session establishment procedure to establish an AIoT session. The PDU session establishment procedure may be a procedure defined in relevant 3GPP specifications (e.g., TS32.255). AIoT session establishment may be performed as shown in patent application No. PCT / CN2022 / 093669. The UE may initiate service modification and release, such as AIoT session modification and AIoT session release, or PDU session modification and PDU session release. Billing information signaling is involved in processes such as service establishment, modification, and release.

[0045] refer to Figure 2The transmission network model can provide 5G system-supported AIoT services to one or more UEs (e.g., UE 10). UE 10 is a 5G terminal that requires AIoT services and applications and can be referred to as a client, client terminal, or AIoT client. gNB 20 is a 5G radio node. gNB 20 communicates with UE 10 and provides NR user plane and control plane protocol termination to the UE through the NR Uu interface. gNB 20 is connected to 5GC 300 through the NG interface. UPF 30b is the UPF in 5GC 300 (which is the 5G core network). DN 40 is the data network (DN) 40 where the application server 41 providing AIoT services resides. DN 40 can provide network operator services, Internet access, or third-party services. Application server 41 may include processor 411, memory 412, and transceiver 413. The processor can be configured to implement the functions, processes, and / or methods related to AIoT services described in the specification. The radio interface protocol layer can be implemented in the processor. The memory 412 is operable to store various programs and information to operate the connected processor. The transceiver 413 is operablely coupled to the connected processor to transmit and / or receive wireless or wired signals.

[0046] Each of processors 411, 11a, 11b, 21a, and 31 may include an application-specific integrated circuit (ASIC), other chipsets, logic circuits, and / or data processing devices. Each of memories 412, 12a, 12b, 22a, and 32 may include read-only memory (ROM), random access memory (RAM), flash memory, memory cards, storage media, and / or other storage devices. Each of transceivers 413, 13a, 13b, 23a, and 33 may include baseband circuitry and radio frequency (RF) circuitry for processing radio frequency signals. When embodiments are implemented in software, the techniques described herein may be implemented using modules, processes, functions, entities, etc., that perform the functions described herein. These modules may be stored in memory and executed by the processor. The memory may be implemented internally or externally to the processor; when the memory is implemented externally, it may be communicatively coupled to the processor in various ways known in the art.

[0047] In the system, a device or UE providing services through AIoT services can be a sending device that transmits AIoT service streams to a receiving device, or a receiving device that receives AIoT service streams. A service data stream 5, such as an AIoT service stream, is established between UE 10 and application server 41. Stream 5 includes a data stream 51 from application server 41 to UE 10 and a data stream 52 from UE 10 to application server 41. Stream 5 transmits the AIoT session or PDU session of UE 10.

[0048] With the development of 5G systems, the 3rd Generation Partnership Project (3GPP) standard has introduced a requirement for 5G systems to support zero-power devices for network access. The main scenarios for these zero-power devices include: extreme environments unsuitable for normal terminal operation; the use of terminals with extremely low power consumption and low cost; and battery-free terminals. Zero-power communication systems can be used in scenarios such as wireless industrial sensor networks, smart agriculture, smart warehousing and logistics, and smart homes. Based on the energy source and application of zero-power devices, they can be categorized as follows:

[0049] 1) Passive Zero-Power Devices: These devices do not require an internal battery. When the device is very close to a network device (e.g., a reader in a Radio Frequency Identification (RFID) system), i.e., when it is within the near field created by the antenna radiation of the network device, the antenna of the zero-power device generates an induced current through electromagnetic induction. This induced current drives the low-power chip circuitry of the zero-power device. This enables the demodulation of forward or downlink signals, as well as the modulation of backward or uplink signals. For backscatter links, passive zero-power devices use backscattered radiation to transmit signals. Therefore, passive zero-power devices do not require an internal battery to drive the forward (or downlink) or backward (or uplink) link; they are truly zero-power devices. The RF and baseband circuitry of passive zero-power devices is very simple, requiring no low-noise amplifiers (LNAs), power amplifiers (PAs), crystal oscillators, analog-to-digital converters (ADCs), or other components, making them small, lightweight, and inexpensive. Therefore, it has advantages such as small size, light weight, very low price and long service life.

[0050] 2) Semi-passive zero-power devices do not have a conventional battery installed, but instead use an RF energy harvesting module to collect radio wave energy and store the collected energy in an energy storage unit (e.g., a capacitor). The energy storage unit then powers the low-power chip circuitry of the zero-power device. Demodulation of the forward link (or downlink) and modulation of the backward link (or uplink) are achieved. For the backscatter link, the zero-power device uses backscattering for signal transmission. Therefore, semi-passive zero-power devices do not require an internal battery to drive the forward (or downlink) or backward (or uplink) link, and the energy stored in the capacitor is used for the operation of the semi-passive zero-power device. This energy comes from the radio energy collected by the energy harvesting module, thus making it a truly zero-power device. Semi-passive zero-power devices inherit many advantages of passive zero-power devices, thus offering advantages such as small size, light weight, high cost, and long lifespan.

[0051] 3) Active zero-power devices can have a built-in battery that powers the low-power chip circuitry of the device. Demodulation of the forward (or downlink) signal and modulation of the backward (or uplink) signal are achieved. However, for backscatter links, active zero-power devices use backscattering to transmit signals. Therefore, these active zero-power devices are mainly used for signal transmission in the backward (or uplink) where the transmission does not require the terminal's own power but instead uses backscattering. Using a built-in battery as a power source for the radio frequency identification (RFID) chip in an active zero-power device can increase the tag's read / write distance and improve communication reliability. Therefore, active zero-power devices are suitable for applications with relatively high requirements such as long communication distances and short read latency.

[0052] Examples of charging reporting methods implemented by the first core network equipment and the second core network equipment. An example of the first core network in the specification may include SMF 30d. An example of the second core network equipment in the specification may include CHF 30e.

[0053] refer to Figure 4 The NF (e.g., SMF 30d) communicates with the CHF (e.g., CHF 30e) via interfaces N40 and Nchf. The NF operates as an NF service consumer. The CHF operates as an NF service producer. In this specification, unless otherwise stated, the SMF can be SMF 30d and the CHF can be CHF 30e.

[0054] CHF is responsible for the converged online and offline billing functions for one or more AIoT sessions or one or more PDU sessions (e.g., Stream 5). CHF provides the following services:

[0055] ●Quota;

[0056] ●Reauthorization triggered;

[0057] ● Notify when the billing domain's rate determination conditions are affected or when CHF determines to terminate the billing service;

[0058] ● Receive service usage reports from NF service consumers; and

[0059] ● CDR generation.

[0060] For one or more AIoT sessions and one or more PDU sessions, such as Stream 5, NF service consumers should support:

[0061] ● Request and receive one or more quotas;

[0062] ● Send service usage reports; and

[0063] ●Process quota reauthorization or suspension notices.

[0064] The CHF, SMF, and other NFs in 5GC can be implemented in one or more instances of network entity device 30 and executed by those instances. NF services can be exposed and provided to NFs in 5GC and NFs of third-party applications through network exposure functions.

[0065] In 5G NR (New Radio), a network function service consumer can be any device that interacts with network functions within the 5G network and consumes the services they provide. These devices may include, but are not limited to, SMF, Short Message Service Function (SMSF), AMF, NEF, Packet Data Network Gateway Control Plane + Session Management Function (PGW-C+SMF), IP Multimedia Subsystem Node (IMS-Node), Connectivity Open Function (CEF), Managed Service Producer (MnS Producer), and 5G Data Driven Network Management Function (5G DDNMF). Devices operating one or more NF service consumers may include:

[0066] User Equipment (UE): This refers to end-user equipment that connects to the 5G network to access various services, such as smartphones, tablets, laptops, IoT devices, and other consumer devices.

[0067] Machine-Type Communication (MTC) devices: These devices are designed specifically for machine-to-machine (M2M) communication and can include sensors, instruments, industrial equipment, connected vehicles, and other IoT devices that require connectivity and services from 5G networks.

[0068] Fixed Wireless Access (FWA) devices: FWA devices provide wireless connectivity in fixed locations, replacing traditional wired broadband connections. These devices include routers, home gateways, and other wireless access devices used for residential or business broadband connections.

[0069] Network Function Virtualization (NFV) infrastructure: NFV infrastructure includes servers, storage devices, and network devices that provide virtualized resources for running network functions in a cloud or data center environment. These resources act as the underlying infrastructure for hosting and executing virtualized network functions.

[0070] Edge computing devices: Edge computing devices (such as edge servers or edge gateways) are deployed closer to the network edge to enable low-latency processing and services. They can use network function services to support edge computing applications and provide localized services.

[0071] Network Management System (NMS) or Operations Support System (OSS): These systems are responsible for managing and monitoring the 5G network, including network functions. They use network function services for network coordination, service provisioning, monitoring, and maintenance.

[0072] Third-party application servers or service providers: Independent application servers or service providers can also use the network function services provided by 5G networks to develop and deliver their own services and applications.

[0073] In summary, network function service consumers in the 5G NR ecosystem can include a variety of devices, including end-user devices, IoT devices, network infrastructure, edge computing devices, management systems, and third-party application servers or service providers.

[0074] refer to Figure 3 The first core network device 30A sends a request 110 for a supported feature, which is used to confirm whether the charging function (CHF) in the core network supports the supported feature, wherein the supported feature includes converged charging service (CCS) for Ambient Internet of Things (AIoT) service types, such as service flow 5 (S12). The second core network device 30B receives the request 110 for the supported feature, which is used to confirm whether the CHF in the core network supports the supported feature (S13).

[0075] In one embodiment, the Nchf_ConvergedCharging application programming interface (API) (which is in Figure 4 The Nchf interface (referred to as Nchf interface) defines the supporting features for CCS for AIoT. As defined in subclause 6.2 of 3GPP TS 32.290, the Nchf_ConvergedCharging service provides billing to NF service consumers by CHF in converged billing scenarios.

[0076] Nchf_ConvergedCharging includes the following features:

[0077] ● Create resources when the service is established or if there are no existing billing data resources, and allocate quotas based on requests from NF consumers;

[0078] ●During the service consumption lifecycle, resources are updated in various situations upon receiving quota usage or service usage reports, and subsequent quotas are allocated based on requests from NF consumers;

[0079] ●Release upon service termination, expiration of the unit count inactive timer, or occurrence of an error response; and

[0080] ● When CHF determines that the rate conditions are affected, notify the NF service consumer to re-authorize the trigger, or when CHF determines to terminate the billing service, notify the NF service consumer to abort the trigger.

[0081] ●Billing information records are generated.

[0082] The API defined in this sub-clause implements the service operations defined in TS32.291 sub-clause 5.2.2.

[0083] In one embodiment, the application programming interface (API) for Nchf_OfflineOnlyCharging (which is in Figure 4 The Nchf interface (referred to as Nchf interface) defines the supporting features for CCS for AIoT. As defined in subclause 6.5 of 3GPP TS 32.290, the Nchf_OfflineOnlyCharging service provides billing to NF service consumers (i.e., SMFs) by CHF in offline-only billing scenarios.

[0084] The Nchf_OfflineOnlyCharging service includes the following features:

[0085] ● Create resources when the service is established based on requests from NF consumers;

[0086] ●During the service consumption lifecycle, resources are updated based on requests from NF consumers;

[0087] ●Release when service terminates;

[0088] ●Billing information records are generated.

[0089] The API defined in this sub-clause implements the service operations defined in sub-clause 5.3.2.1 of TS32.291.

[0090] The Nchf_ConvergedCharging service should use the Nchf_ConvergedCharging API. It provides either converged charging services or offline-only charging services to NF service consumers via CHF. Converged charging services (Nchf_ConvergedCharging) or offline-only charging services (Nchf_OfflineOnlyCharging) are part of the Nchf service-based interface exposed by the Charging Function (CHF).

[0091] The request URI used in every HTTP request from an NF service consumer to a CHF should have the structure defined in subclause 4.4.1 of 3GPP TS29.501.

[0092] In one embodiment, the request is sent in the 5G core network (5GC) during feature negotiation within a scalability mechanism supported by the service-based architecture. The supported feature in the request can be one of several optional features defined in Table 6.1.8-1 of TS 32.291 for the Nchf_ConvergedCharging API. These features should be negotiated using the scalability mechanism defined in Sub-clause 6.6 of 3GPP TS 29.500. A CCS for AIoT can be added as a new optional feature in Table 6.1.8-1 of TS 32.291. The following table shows the version of Table 6.1.8-1 in TS 32.291 with the addition of a CCS for AIoT as a new entry “5GSAIoT”.

[0093] Table 2: New version of Table 6.1.8-1: Supported features

[0094]

[0095] The second core network device determines whether the CHF supports the supported feature (S15), and when the CHF supports the supported feature, sends a response 111 to request 110 (S17). Response 111 indicates that the CHF supports the CCS supported feature. Response 111 enables signaling, for example, sending Protocol Data Unit (PDU) session billing information for CCS for AIoT from the CHF to the SMF or from the SMF to the CHF, between the first core network device and the second core network device.

[0096] When the first core network device receives a successful response to the request, it determines that CHF supports the CCS support feature. When the first core network device does not receive a successful response to the request, it determines that CHF does not support the CCS support feature.

[0097] When the first core network device and the second core network device receive a response indicating that CHF supports the CCS support feature, they execute signaling (S18) for Protocol Data Unit (PDU) session billing information for CCS for AIoT.

[0098] Signaling for PDU session billing information of CCS for AIoT is used in the service establishment process, service modification process, or service release process.

[0099] In one embodiment of the present invention, the service establishment process includes an AIoT session establishment process or a PDU session establishment process. The service modification process includes an AIoT session modification process or a PDU session modification process. The service release process includes an AIoT session release process or a PDU session release process.

[0100] Introduce new parameters (or information elements) as PDU session billing information for CCS used in AIoT. These new parameters can be included in Table 6.2.1.2.1, “Definition of PDU Session Billing Information,” of TS 32.255. The PDU session billing information provides PDU session-specific billing information for 5G data connection billing in AIoT.

[0101] The detailed structure of PDU session billing information can be found in Table 6.2.1.2.1 of TS 32.255, and this disclosure adds new entries for AIoT to that table.

[0102] Table 3: New entries for new information elements added to Table 6.2.1.2.1 (Structure of PDU Session Billing Information)

[0103]

[0104] In one or more embodiments, the PDU session billing information includes a field for indicating control plane fifth-generation system (5GS) AIoT optimization. If this support feature of the CCS for AIoT is enabled, the field contains an indicator indicating whether 5GS control plane optimized AIoT is used / enabled during an AIoT session or PDU session.

[0105] In one or more embodiments, the PDU session billing information includes a field for AIoT small data rate control indication. This field contains an indicator indicating whether 5GS AIoT small data rate control is used / enabled during an AIoT session or PDU session.

[0106] In one or more embodiments, the PDU session billing information includes a field for AIoT-only control plane indication. This field contains an indicator indicating whether only the control plane is used / enabled, where only the control plane is used is a mode that only transmits PDU data to the control plane in the case of AIoT-optimized control plane.

[0107] In one or more embodiments, PDU session billing information includes a field or Radio Access Technology (RAT) type. This field contains the service RAT. The service RAT includes the AIoT access type.

[0108] For the support feature CCS for AIoT, a new RAT type “AIoT” can be added in Table 5.4.3.2-1 (Enumeration RatType of 3GPP TS 29.571), as shown in the table below.

[0109] Table 4: A new version of Table 5.4.3.2-1 (Enumeration RatType of 3GPP TS 29.571) with a new RAT type "AIoT" for the support feature CCS for AIoT.

[0110]

[0111] The supporting features carried in the request can initially be supported by the NF service consumer and sent in a request to confirm whether the supporting features are also supported by the NF service producer. The NF service producer replies with a successful response, conveying the supporting feature to the NF service consumer to indicate that the request was granted and that the supporting feature is indeed supported by the NF service producer. This request is a Hypertext Transfer Protocol (HTTP) request, and the response is an HTTP response. When a successful response to the request is received, the CHF supports the CCS supporting features. When the first core network device does not receive a successful response to the request, the CHF does not support the CCS supporting features. This interactive process is called feature negotiation.

[0112] Before using such a query parameter in an HTTP request, NF service consumers should, if possible, use the feature negotiation mechanism specified in Clause 6.6.2 of TS 29.500 to determine whether the NF service producer supports the query parameter.

[0113] If an NF service consumer includes a query parameter of the SupportedFeatures data type (e.g., “supported-features”) as defined in 3GPP TS 29.571 in its HTTP GET request, then the NF service producer should include an attribute of the SupportedFeatures data type (e.g., “SupportedFeatures”) as defined in 3GPP TS 29.571 in its HTTP GET response, provided that the API definition supports it, as defined in Clause 6.6.2 of TS 29.500 for HTTP responses.

[0114] This allows NF service consumers to discover features (and query parameters) supported by the NF service producer when their first interaction with the NF service producer is an HTTP GET request and the service is not discovered via NRF (e.g., for an NF discovery request sent to NRF).

[0115] If an NF service consumer (e.g., a first core network device or SMF) uses such query parameters in an HTTP GET request without prior knowledge of whether they are supported by the NF service producer, the NF service consumer should be prepared to receive a successful response that may not match any of the query parameters sent in the request and to act accordingly. The NF service consumer can use the attributes of the SupportedFeatures data type, as defined in 3GPP TS 29.571, returned by the NF service producer in the HTTP GET response (if available) to determine whether the NF service producer does not support these features (and query parameters).

[0116] The 5G APIs, including the Nchf_ConvergedCharging API, will use a mechanism for negotiating applicable optional features. This supported feature mechanism should be applied individually to each API.

[0117] For any API that defines a resource, the appropriate resource associated with or representing an NF service consumer (e.g., a top-level resource or sub-resource representing an NF service consumer) should be identified in each API to facilitate negotiation between the NF service consumer and the NF service producer regarding applicable optional features for that resource. Each such resource in a 5G API should contain an attribute of the SupportedFeatures data type (e.g., “supportedFeatures”) as defined in 3GPP TS 29.571, which contains a bitmask indicating supported features. The features in this bitmask and their locations are defined separately for each API.

[0118] HTTP clients acting as NF service consumers should include an attribute of the SupportedFeatures data type as defined in 3GPP TS 29.571 in their HTTP PUT or POST requests to create resources associated with or representing the NF service consumer of the 5G API. This attribute indicates which of the multiple optional features (e.g., CCS for AIoT) defined for the corresponding service (e.g., AIoT) the HTTP client supports. The HTTP server (i.e., the NF service producer) should determine the supported features of the corresponding resource by comparing the supported features indicated by the client with the supported features supported by the HTTP server. Features supported by both the client and server are supported for that resource (e.g., a resource associated with or representing an SMF). The HTTP server should include an attribute of the SupportedFeatures data type as defined in 3GPP TS 29.571, indicating which features in the resource representation it returns to the HTTP client in the HTTP response confirming resource creation.

[0119] An HTTP client acting as an NF service consumer can include a query parameter of the SupportedFeatures data type (e.g., "Supported Features") as defined in 3GPP TS 29.571 in an HTTP GET request to retrieve one or more resources associated with the NF service consumer of the 5G API. This query parameter indicates which of several optional features defined for the corresponding service the HTTP client supports. The HTTP server should determine the supported features of the one or more corresponding resources by comparing the supported features indicated by the client with the supported features supported by the HTTP server. Features supported by both the client and the server are supported for that one or more resources (e.g., resources associated with or representing an SMF). Attributes or enumeration values ​​related only to features not supported by the requested one or more resources should be omitted from the representation sent in the response. If the API definition supports them, the HTTP server should include an attribute of the SupportedFeatures data type as defined in 3GPP TS 29.571 that indicates which features are supported in the HTTP GET response.

[0120] Support features for resources associated with or representing NF service consumers should also apply to all dependent resources of that resource, as well as all custom operations associated with any of these resources.

[0121] Attributes, specific values ​​in enumerated data types, and / or process descriptions used to represent resources (e.g., resources associated with or representing an SMF) may be marked as being associated with specific supported features. Unknown attributes and values ​​will be ignored by the receiving entity. Unsupported query parameters shall be handled in accordance with Clause 5.2.9 of TS 29.500.

[0122] refer to Figure 5 The data connectivity domain converged billing architecture includes an SMF that embeds a charge trigger function (CTF).

[0123] The SMF with embedded CTF generates a billing event for CHF, which is used for data connection convergence billing or offline-only billing.

[0124] As described in TS 32.240, the CTF generates a charging event for the CHF, which is used to merge online and offline charging processing. CDR generation is performed by the CHF as a Charging Data Function (CDF), which passes the CDR to the Charging Gateway Function (CGF).

[0125] Finally, CGF creates CDR files and forwards these CDR files to the Accounting Domain (BD).

[0126] If the CGF is external, the CHF acts as the CDF, forwarding the CDR to the CGF via the Ga interface. Ga is the reference point used for CDR transfer between the CDF and CGF.

[0127] If the CGF is integrated, there is only one internal interface between the CHF and the CGF. In this case, the relationship between the CHF and the CGF is 1:1. The integrated CGF can support Ga interfaces from other CDFs.

[0128] When using an external CGF, depending on network design and operator decisions, the CGF can also be used by other (i.e., non-5GCS) network components. It should be noted that the CGF can also be an integrated component of the BD—in this case, the Bd interface does not exist and is replaced by a proprietary solution within the BD. The Bd serves as the reference point for transferring CDR files from the 5G data connection CGF to the BD.

[0129] During service setup (e.g., AIoT session setup or PDU session setup), an initial billing request will be sent from the SMF or the CTF within the SMF to the CHF. In this request, the SMF may provide the CHF with the following new billing information related to 5GS AIoT.

[0130] The signaling for PDU session billing information in CCS for AIoT includes at least one or more of the following, as well as other PDU session billing information:

[0131] (1). Control plane 5GS AIoT optimization indicator: If the feature (i.e., the CCS support feature for AIoT) is enabled, this field contains an indicator indicating whether control plane optimization for 5GS is used / enabled during an AIoT session or PDU session.

[0132] (2). AIoT Small Data Rate Control Indicator: This field contains an indicator that indicates whether 5GS AIoT small data rate control is used / enabled during an AIoT session or PDU session.

[0133] (3). AIoT Control Plane Only Indicator: This field contains the following indicator: This indicator indicates whether the control plane is used / enabled only, that is, in the case of AIoT optimization of the control plane, only PDU data is passed to the control plane.

[0134] (4). RAT type: This field contains the Radio Access Technology (RAT) currently serving the UE. For AIoT, this field contains the Radio Access Technology (RAT) associated with AIoT.

[0135] The parameters defined above are the new parameters required for applying billing reports from SMF to CHF. CHF needs them to properly bill AIoT services.

[0136] In some embodiments, AIoT session establishment is based on PDU session establishment. In some embodiments, AIoT session establishment is not based on PDU session establishment.

[0137] refer to Figures 6 to 9 The following is a detailed description of an example of the AIoT session establishment process.

[0138] Below, in conjunction with Figures 6 to 9 Taking the aforementioned device (or UE) as an example, the method provided in the above embodiments will be described in detail:

[0139] S601: The target service provider provides parameters of candidate devices to the core network equipment.

[0140] The core network device can be any one of one or more candidate core network devices, and this candidate core network device can be a candidate AMF (Advanced Management Function). Specifically, this step can involve the target service provider sending parameters of the device it manages to any one of the one or more candidate AMFs, and the candidate AMF that receives the device parameters from the target service provider updating its pre-configuration information. The pre-configuration information can be stored in a shared database, allowing one or more AMFs to share the pre-configuration information.

[0141] Note that the processing described in S601 is performed only by the target service provider. In actual processing, there may be one or more candidate service providers. Therefore, the pre-configuration information described above may include parameters of the candidate device corresponding to each of the one or more candidate service providers. Specifically, the parameters of the candidate device corresponding to each candidate service provider are configured by each candidate service provider to one of the one or more candidate core network devices. The parameters of the candidate device include at least one of the following: the ID of the candidate device; the service area of ​​the candidate device; the ID of the candidate device manufacturer; and the identifier of the candidate service provider.

[0142] S602: Core network devices store device parameters in pre-configuration information and share this pre-configuration information among different core network devices.

[0143] S603: The device is pre-configured with at least one of the following: routing-related information; device manufacturer ID; service provider ID; and terminal device ID. Routing-related information includes at least one of the following: routing-related ID; and routing path information. The routing-related ID may include at least one of the following: the ID of the routing information; and the ID of the target service provider.

[0144] Furthermore, the execution order of S603 and S601 to S602 is not fixed. They can be executed simultaneously, or S601 to S602 can be executed before S603; or S603 can be executed before S601 to S602.

[0145] After the above processing is completed, the device can send uplink data information to the gNB when service data needs to be sent. Specifically, such as... Figure 7 The terminal device depicted represents the aforementioned device, and for illustrative purposes, the first access and mobility management function (AMF) is exemplified by the first core network device.

[0146] S701: When the device is located in the target area, the device establishes an access stratum (AS) connection with the gNB.

[0147] S702: The device sends uplink data information to the gNB.

[0148] Specifically, the device sends uplink data information to the gNB through an AS connection established with the gNB. This uplink data information can be an uplink data container, and specifically, a UL AIoT data container. The header of the UL AIoT data container may include at least one of the following first pieces of information: a routing-related ID; a device manufacturer ID; and a service provider ID. The first pieces of information include routing-related information. Alternatively, the first pieces of information may also include at least one of the following: a device manufacturer identifier; a service provider identifier; and a terminal device identifier.

[0149] S703: gNB determines the first AMF based on the first information in the uplink data information.

[0150] Specifically, the gNB can select the first AMF based on at least one of the routing-related ID, device manufacturer ID, and service provider ID carried in the header portion of the uplink data container, and at least one of the service provider ID.

[0151] If the header of the uplink data container does not carry at least one of the routing-related ID, device manufacturer ID, and service provider ID (the first information), the gNB arbitrarily selects an AMF as the first AMF. Furthermore, similar to the aforementioned embodiments, if the header of the uplink data container does not carry at least one of the routing-related ID, device manufacturer ID, or service provider ID (the first information), the gNB can select an AMF as the first AMF based on the device ID carried in the data payload.

[0152] S704: gNB sends uplink data information to the first AMF.

[0153] Specifically, the gNB sends a UL AIoT data container to the first AMF.

[0154] S705: The first AMF determines the target service provider based on the first information in the uplink data information.

[0155] S706: The first AMF sends uplink data information to the target service provider.

[0156] Here, although not shown in the figure, in one scenario, the first AMF can send uplink data information to the target service provider via the Network Open Function (NEF).

[0157] S707: The target service provider sends downlink data information to the first AMF.

[0158] Specifically, downlink data information is a response to uplink data information. Downlink data information may include a device ID. Downlink data information can be encapsulated into a DL data container. That is, when a target service provider has DL data to send to the device, the target service provider can send the DL data container to the first AMF (Advanced Management Function).

[0159] Here, although not shown in the figure, in one scenario, the target service provider (SP) can send downlink data information to the first AMF via NEF.

[0160] S708: The first AMF sends downlink data information to the gNB.

[0161] S709: gNB sends downlink data information to the device.

[0162] For illustrative purposes, an example is provided below, where the terminal device represents a device, the gNB represents an access network device, and the first AMF represents a first core network device, such as... Figure 8 As shown. This example includes the following operations:

[0163] S801: The device sends a registration request message to the first AMF via gNB.

[0164] In other words, during the process of establishing a NAS connection between the device and the first AMF, the first operation performed may include: establishing an RRC connection between the device and the gNB, and carrying a NAS message in the RRC message. Here, the NAS message refers to a registration request message, and the NAS message includes the device ID, registration type, etc.

[0165] In an embodiment of the present invention, the registration request may include a request 110 sent from the SMF to the CHF.

[0166] S802: The device receives a registration acceptance message sent by the first AMF via the gNB, wherein the registration acceptance message carries the ID of the target service provider.

[0167] Specifically, after the first AMF obtains the user data of the device, the first AMF returns a registration acceptance message to the device. This message may carry a 5th Generation Globally Unique Temporary Identifier (5G-GUTI) or the ID of the target service provider. The ID of the target service provider may be represented as the AIoT business provider ID.

[0168] The AIoT service provider ID is used to indicate the target ID (i.e., the ID of the target service provider) of the device sending AIoT data.

[0169] It should be understood that in S802, the registration acceptance message may not carry the target service provider's ID. The target service provider's ID can be pre-configured in the terminal device (i.e., the device).

[0170] S803: The device returns a registration completion message to the first AMF via the NAS connection.

[0171] S804: The device sends the uplink data information carried in the uplink NAS transmission message to the first AMF.

[0172] In other words, when the device is connected, it sends a UL NAS TRANSPORT (Uplink NAS Transmission Message) message on the NAS connection. This message includes uplink data information (specifically, AIoT data). The uplink data information may also include the target service provider's ID. The target service provider's ID can be content contained in the routing information within the uplink data information. Similar to the example above, the uplink data information can be an uplink data container, specifically a UL AIoT data container. The header of the UL AIoT data container may include the target service provider's ID as first information. The first information includes: routing-related information. Alternatively, the first information may also include at least one of the following: the device manufacturer's ID; the service provider's ID; and the end device's ID.

[0173] S805: The first AMF sends uplink data information to the target service provider.

[0174] Specifically, the first AMF sends uplink data information to the appropriate service provider based on the target service provider ID (which can be represented as AIoT service provider ID) contained in the first information of the uplink data information carried in the uplink NAS transmission message.

[0175] The steps for sending downlink data are as follows:

[0176] S806: The target service provider sends downlink data information to the first AMF.

[0177] Downlink data information is a DL data container carried in the DL transmission message, and the downlink data information also needs to carry the device ID.

[0178] S807: The first AMF sends downlink data information carried in the downlink NAS transmission message to the device.

[0179] In other words, the first AMF carries downlink data information in the DL NAS TRANSPORT message (downlink NAS transmission message) and sends the message to the device. The message carries downlink data information (specifically, the downlink data information can be an AIoT data container).

[0180] The following example uses the terminal device as the "device," the access network device as the gNB, and the first core network device as the first AMF. (Combined with...) Figure 9 This embodiment describes another exemplary communication method, which includes:

[0181] S901: The device sends uplink data information carried in the control plane service request message to the first AMF.

[0182] The difference between this step and the example described above is that the registration process described in S801 to S803 may have been completed before S901 is executed.

[0183] However, the device is currently in an idle state (or a disconnected state). At this time, if the device has AIoT data (i.e., uplink data information) to send, it can directly send a control plane service request message to the first AMF (this message can enable the device to enter a connected state). It is the same as the aforementioned exemplary description and will not be repeated here.

[0184] In an embodiment of the present invention, the control plane service request message may include a request 110 sent from the SMF to the CHF.

[0185] S902: The first AMF sends uplink data information to the target service provider.

[0186] Specifically, the first AMF sends the uplink data information to the appropriate service provider based on the target service provider ID (which can be represented as the AIoT service provider ID) contained in the uplink data information carried in the uplink NAS transmission message.

[0187] The steps for sending downlink data are as follows:

[0188] S903: The target service provider sends downlink data information to the first AMF.

[0189] S904: The first AMF sends downlink data information carried in the downlink NAS transmission message to the device.

[0190] Here, the processing in S903 and S904 is the same as that in S806 and S807 in the previous example, and will not be repeated here. It is evident that by adopting the above scheme, the network-side device can determine the target service provider for this data transmission based on the uplink data information sent by the terminal device, and directly send the uplink data information to the target service provider. This reduces the need for the terminal device to perform complex communication processes to transmit data to the network side, and also reduces the signaling overhead caused by complex communication processes. This is especially suitable for zero-power terminals, given their low complexity.

[0191] like Figure 10 As shown, embodiments of this application relate to a first core network system 300A and a second core network system 300B. The first core network system 300A includes:

[0192] Transceiver module 501A is configured to send a request for a supported feature to confirm whether the charging function (CHF) in the core network supports the supported feature, wherein the supported feature includes Converged Charging Service (CCS) for Ambient Internet of Things (AIoT) service types.

[0193] Billing function module 502A is configured to execute signaling for Protocol Data Unit (PDU) session billing information for AIoT CCS when a response indicating CHF support for CCS is received.

[0194] The second core network system 300B includes:

[0195] Transceiver module 501B is configured to receive a request for a supported feature, the request being used to confirm whether the charging function (CHF) in the core network supports the supported feature, wherein the supported feature includes Converged Charging Service (CCS) for Ambient Internet of Things (AIoT) service types.

[0196] Billing function module 502B is configured to execute signaling for Protocol Data Unit (PDU) session billing information for AIoT CCS when CHF supports the supported function; and

[0197] Determining module 503B is configured to determine whether CHF supports the supported feature.

[0198] When CHF supports this support feature, transceiver module 501B sends a response to the request indicating that CHF supports the CCS support feature, wherein the response enables signaling for Protocol Data Unit (PDU) session billing information for CCS for AIoT.

[0199] When the billing function module 502B receives a response indicating that CHF supports the CCS support feature, it executes signaling for the Protocol Data Unit (PDU) session billing information for CCS for AIoT.

[0200] It is understood that this implementation is an embodiment of the device corresponding to any embodiment in the plurality of embodiments, and this embodiment can be implemented in combination with any embodiment in the plurality of embodiments. The relevant technical details mentioned in any embodiment in the plurality of embodiments still apply in this embodiment, and will not be repeated here to reduce repetition. Therefore, the relevant technical details mentioned in this embodiment can also be applied to any embodiment in the plurality of embodiments.

[0201] It is worth noting that each module involved in this embodiment is a logic module. In practical applications, a logic unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. A physical module can be a circuit, an integrated circuit (IC), a chipset, or a circuit module. A logic module can be a computer program, a software module, or a combination of logic and physical modules. Furthermore, to highlight the innovative aspects of this invention, this embodiment does not describe units that are not closely related to solving the technical problems proposed by this invention; however, this does not mean that other units do not exist in this embodiment.

[0202] In one embodiment, the first core network system 300A may be installed in and executed by the first core network device 30A, and the second core network system 300B may be installed in and executed by the second core network device 30B.

[0203] Figure 11 This is a block diagram of an example system 700 for wireless communication according to embodiments of the present disclosure. The embodiments described herein can be implemented in the system using any suitably configured hardware and / or software. Figure 11 The system 700 is shown, which includes a radio frequency (RF) circuit 710, a baseband circuit 720, a processing unit 730, a memory / storage device 740, a display 750, a camera 760, a sensor 770, and an input / output (I / O) interface 780 that are coupled to each other as shown.

[0204] Processing unit 730 may include circuitry, such as, but not limited to, one or more single-core or multi-core processors. The processor may include any combination of general-purpose and special-purpose processors, such as graphics processors and application processors. The processor may be coupled to a memory / storage device and configured to execute instructions stored in the memory / storage device to enable various applications and / or operating systems to run on the system.

[0205] Baseband circuitry 720 may include circuitry, such as, but not limited to, one or more single-core or multi-core processors. The processor may include a baseband processor. The baseband circuitry can handle various radio control functions that enable communication with one or more wireless networks via RF circuitry. Radio control functions may include, but are not limited to, signal modulation, encoding, decoding, RF offset, etc. In some embodiments, the baseband circuitry can provide communication compatible with one or more wireless technologies. For example, in some embodiments, the baseband circuitry may support communication with 5G NR, LTE, Evolved Universal Terrestrial Radio Access Network (EUTRAN) and / or other wireless metropolitan area networks (WMAN), wireless local area networks (WLAN), and wireless personal area networks (WPAN). Embodiments of the baseband circuitry configured to support radio communication using more than one wireless protocol may be referred to as multi-mode baseband circuitry. In various embodiments, baseband circuitry 720 may include circuitry that operates on signals not strictly considered to be at baseband frequencies. For example, in some embodiments, the baseband circuit may include circuitry that operates on a signal having an intermediate frequency, which is between the baseband frequency and the radio frequency.

[0206] RF circuit 710 can communicate with a wireless network using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuit may include switches, filters, amplifiers, etc., to facilitate communication with the wireless network. In various embodiments, RF circuit 710 may include circuitry that operates on signals that are not strictly considered to be radio frequency (RF). For example, in some embodiments, the RF circuit may include circuitry that operates on signals having an intermediate frequency (IF), which is between the baseband frequency and the RF frequency.

[0207] In various embodiments, the transmitter circuitry, control circuitry, or receiver circuitry discussed above with respect to the UE, eNB, or gNB may be embodied, wholly or partially, in one or more of the RF circuitry, baseband circuitry, and / or processing unit. As used herein, “circuit” may refer to, be part of, or include: an application-specific integrated circuit (ASIC), electronic circuitry, a (shared, dedicated, or grouped) processor and / or (shared, dedicated, or grouped) memory executing one or more software or firmware programs; combinational logic circuitry; and / or other suitable hardware components providing the aforementioned functionality. In some embodiments, electronic device circuitry may be implemented in one or more software or firmware modules, or the functionality associated with the circuitry may be implemented by one or more software or firmware modules. In some embodiments, some or all of the components of the baseband circuitry, processing unit, and / or memory / storage device may be implemented together on a system on a chip (SOC).

[0208] The memory / storage device 740 can be used to load and store, for example, data and / or instructions for the system. One embodiment of the memory / storage device may include any combination of suitable volatile memory (e.g., dynamic random access memory, DRAM) and / or non-volatile memory (e.g., flash memory). In various embodiments, the I / O interface 780 may include one or more user interfaces designed to enable a user to interact with the system and / or peripheral component interfaces designed to enable peripheral components to interact with the system. User interfaces may include, but are not limited to, a physical keyboard or keypad, a touchpad, a speaker, a microphone, etc. Peripheral component interfaces may include, but are not limited to, non-volatile memory ports, universal serial bus (USB) ports, audio jacks, and power interfaces.

[0209] In various embodiments, sensor 770 may include one or more sensing devices for determining environmental conditions and / or location information relevant to the system. In some embodiments, the sensor may include, but is not limited to, a gyroscope sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit. The positioning unit may also be part of, or interact with, baseband and / or RF circuitry to communicate with components of a positioning network (e.g., global positioning system (GPS) satellites). In various embodiments, display 750 may include displays such as liquid crystal displays and touchscreen displays. In various embodiments, system 700 may be a mobile computing device, such as, but not limited to, laptops, tablets, netbooks, ultrabooks, smartphones, etc. In various embodiments, the system may have more or fewer components and / or different architectures. Where appropriate, the methods described herein may be implemented as a computer program. The computer program may be stored on a storage medium, such as a non-transitory storage medium.

[0210] Embodiments of this disclosure are combinations of technologies / processes that can be employed in 3GPP specifications to create a final product.

[0211] Those skilled in the art will understand that each of the units, algorithms, and steps described and disclosed in the embodiments of this disclosure is implemented using electronic hardware or a combination of computer software and electronic hardware. Whether these functions operate in hardware or software depends on the application conditions and the design requirements of the technical solution. Those skilled in the art can implement the functions of each specific application in different ways, and such implementation should not exceed the scope of this disclosure. Those skilled in the art will understand that he / she can refer to the working process of the systems, devices, and units in the above embodiments, as the working processes of the above systems, devices, and units are substantially the same. For ease of description and simplification, these working processes will not be described in detail.

[0212] It should be understood that the systems, devices, and methods disclosed in the embodiments of this disclosure can be implemented in other ways. The above embodiments are merely exemplary. The division of units is based solely on logical function, while other divisions exist in the implementation. It is possible to combine or integrate multiple units or components into another system. It is also possible to omit or skip certain features. On the other hand, the mutual coupling, direct coupling, or communication coupling shown or discussed, whether implemented indirectly in an electrical, mechanical, or other form or through communication, operates through some ports, devices, or units.

[0213] The units used for explanation may or may not be physically separate. The units used for display may or may not be physical units, i.e., located in one place or distributed across multiple network units. Some or all units may be used depending on the purpose of the embodiment. Furthermore, in multiple embodiments, each functional unit among the multiple functional units in each embodiment may be integrated into a single processing unit, physically independent, or integrated into a single processing unit with two or more units.

[0214] If software functional units are implemented, used, and sold as a product, they can be stored in a readable storage medium within a computer. Based on this understanding, the technical solutions proposed in this disclosure can be implemented substantially or partially in the form of a software product. Alternatively, a portion of a technical solution beneficial to conventional technology can be implemented in the form of a software product. The software product in the computer is stored in a storage medium and includes multiple commands for a computing device (e.g., a personal computer, server, or network device) to execute all or some of the steps disclosed in the embodiments of this disclosure. The storage medium includes a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a floppy disk, or other types of media capable of storing program code.

[0215] For any new service in 3GPP, billing reporting is required from the core network 5GS / 5GC to the Billing Function (CHF). This is crucial for enabling billing of a specific service within the service provider's billing domain and ultimately monetizing that service, thus achieving a return on investment (ROI) when deploying it. This also applies to Ambient IoT. This invention defines how billing reporting will be applied to Ambient IoT and defines the corresponding parameters required for such billing reporting. Ultimately, it is expected that the corresponding 3GPP standards (e.g., TS 23.501 with AIoT session definitions, and TS 32.255 (Billing Reporting Phase 2) and TS 32.291 (Billing Reporting Phase 3)) will be extended to support this transaction and the mentioned parameters.

[0216] While this disclosure has been described in conjunction with what are considered to be the most practical and preferred embodiments, it should be understood that this disclosure is not limited to the disclosed embodiments, but is intended to cover various arrangements made without departing from the broadest interpretation of the appended claims.

Claims

1. A charging reporting method performed by a first core network device, comprising: sending a request for support features, the request being for confirming whether a charging function, CHF, in a core network supports the support features, wherein the support features include a converged charging service, CCS, for ambient Internet of Things, AIoT, traffic type; and performing, when receiving a response to the request indicating that the CHF supports the support features of the CCS, a protocol data unit, PDU, session charging information signaling of the CCS for AIoT.

2. The charging reporting method of claim 1, wherein, The PDU session charging information signaling of the CCS for AIoT is used in a service establishment procedure, a service modification procedure, or a service release procedure.

3. The charging reporting method of claim 2, wherein, The service establishment procedure includes an AIoT session establishment procedure or a PDU session establishment procedure; The service modification procedure includes an AIoT session modification procedure or a PDU session modification procedure; and The service release procedure includes an AIoT session release procedure or a PDU session release procedure.

4. The charging reporting method of claim 1, wherein, The PDU session charging information includes a field for an indication of control plane Fifth Generation System, 5GS, AIoT optimization; and If the support features of the CCS for AIoT are enabled, the field contains an indicator indicating whether control plane optimization AIoT for 5GS is used / enabled during an AIoT session or a PDU session.

5. The charging reporting method of claim 1, wherein, The PDU session charging information includes a field for an AIoT small data rate control indication; and The field contains an indicator indicating whether small data rate control for 5GS AIoT is used / enabled during an AIoT session or a PDU session.

6. The charging reporting method of claim 1, wherein, The PDU session charging information includes a field for an AIoT control plane only indication; and The field contains an indicator indicating whether control plane only is used / enabled, wherein the control plane only is a mode of transferring PDU data to a control plane only in case of control plane AIoT optimization.

7. The charging reporting method of claim 1, wherein, The PDU session charging information includes a field or a radio access technology, RAT, type; and The field contains a serving RAT.

8. The charging reporting method of claim 7, wherein, The serving RAT includes an AIoT access type.

9. The charging reporting method of claim 1, wherein, The support features of the CCS for AIoT are defined for an Nchf_ConvergedCharging application programming interface, API.

10. The charging reporting method of claim 1, wherein, The first core network device includes a network function, NF, service consumer.

11. The charging reporting method of claim 1, wherein, The first core network device includes a session management function, SMF.

12. The charging reporting method of claim 1, wherein, The request is sent during feature negotiation in a scalability mechanism supported in a service-based architecture in a 5G core network, 5GC.

13. The charging reporting method of claim 1, wherein, The first core network device determines that the CHF supports the support features of the CCS when receiving a successful response to the request; and The first core network device determines that the CHF does not support the support features of the CCS when the first core network device does not receive the successful response to the request.

14. The charging reporting method of claim 13, wherein, The request is a hypertext transfer protocol, HTTP, request; and The response is an HTTP response.

15. A user equipment, UE, comprising: a processor configured to invoke and run a computer program stored in a memory to cause a device in which the processor is installed to perform the method according to any one of claims 1 to 14.

16. A chip comprising: a processor configured to invoke and run a computer program stored in a memory to cause a device in which the chip is installed to perform the method according to any one of claims 1 to 14.

17. A computer readable storage medium having stored therein a computer program, wherein, The computer program causes a computer to perform the method according to any one of claims 1 to 14.

18. A computer program product comprising a computer program, wherein, The computer program causes a computer to perform the method according to any one of claims 1 to 14.

19. A computer program, wherein, The computer program causes a computer to perform the method according to any one of claims 1 to 14.

20. A charging reporting method performed by a second core network device, comprising: receiving a request for supporting features, the request being used to confirm whether a charging function CHF in a core network supports the supporting features, wherein the supporting features include a converged charging service CCS for an ambient Internet of Things AIoT service type; determining whether the CHF supports the supporting features; and when the CHF supports the supporting features, sending a response to the request, the response indicating that the CHF supports the supporting features of the CCS, wherein the response enables signaling of protocol data unit PDU session charging information of the CCS for AIoT.

21. The charging reporting method of claim 20, wherein, The signaling of the PDU session charging information of the CCS for AIoT is used in a service establishment procedure, a service modification procedure, or a service release procedure.

22. The charging reporting method of claim 21, wherein, The service establishment procedure includes an AIoT session establishment procedure or a PDU session establishment procedure; The service modification procedure includes an AIoT session modification procedure or a PDU session modification procedure; and The service release procedure includes an AIoT session release procedure or a PDU session release procedure.

23. The charging reporting method of claim 20, wherein, The PDU session charging information includes a field for an indication of control plane Fifth Generation System 5GS AIoT optimization; and If the supporting features of the CCS for AIoT are enabled, the field contains an indicator indicating whether control plane optimization AIoT for 5GS is used / enabled during an AIoT session or a PDU session.

24. The charging reporting method of claim 20, wherein, The PDU session charging information includes a field for an AIoT small data rate control indication; and The field contains an indicator indicating whether small data rate control for 5GS AIoT is used / enabled during an AIoT session or a PDU session.

25. The charging reporting method of claim 20, wherein, The PDU session charging information includes a field for an AIoT control plane only indication; and The field contains an indicator indicating whether control plane only is used / enabled, wherein the control plane only is a mode of transferring PDU data to a control plane only in the case of control plane AIoT optimization.

26. The charging reporting method of claim 20, wherein, The PDU session charging information includes a field or a radio access technology RAT type; and The field contains a serving RAT.

27. The charging reporting method of claim 26, wherein, The serving RAT includes an AIoT access type.

28. The charging reporting method of claim 20, wherein, The support feature of the CCS for AIoT is defined for Nchf_ConvergedCharging Application Programming Interface, API.

29. The charging reporting method of claim 20, wherein, The first core network device comprises a Network Function, NF, service consumer.

30. The charging reporting method of claim 20, wherein, The first core network device comprises a Session Management Function, SMF.

31. The charging reporting method of claim 20, wherein, The second core network device comprises a Charging Function, CHF.

32. The charging reporting method of claim 20, wherein, The request is received during feature negotiation in a scalability mechanism supported in a service-based architecture in a 5G Core Network, 5GC.

33. The charging reporting method of claim 20, wherein, The CHF supports the support feature of the CCS when a successful response to the request is received; and The CHF does not support the support feature of the CCS when the first core network device does not receive the successful response to the request.

34. The charging reporting method of claim 33, wherein, The request is a HyperText Transfer Protocol, HTTP, request; and The response is an HTTP response.

35. A user equipment, UE, comprising: a processor configured to invoke and run a computer program stored in a memory to cause a device in which the processor is installed to perform the method according to any one of claims 20 to 34.

36. A chip comprising: a processor configured to invoke and run a computer program stored in a memory to cause a device in which the chip is installed to perform the method according to any one of claims 20 to 34.

37. A computer readable storage medium having stored therein a computer program, wherein, The computer program causes a computer to perform the method according to any one of claims 20 to 34.

38. A computer program product comprising a computer program, wherein, The computer program causes a computer to perform the method according to any one of claims 20 to 34.

39. A computer program, wherein, The computer program causes a computer to perform the method according to any one of claims 20 to 34. The computer program causes a computer to perform the method according to any one of claims 20 to 34.

Images