Patent Description:
To meet the increasing demand with respect to wireless data traffic after the commercialization of <NUM>th generation (<NUM>) communication systems, efforts to develop an enhanced <NUM>th generation (<NUM>) communication system or a pre-<NUM> communication system are continuing. For this reason, a <NUM> communication system or pre-<NUM> communication system is called a Beyond <NUM> Network communication system or a post long term evolution (LTE) system. The <NUM> communication system defined by the <NUM>rd generation Partnership Project (3GPP) is called a new radio (NR) system. To achieve a high data transmission rate, the implementation of <NUM> communication systems in an ultra-high-frequency millimeter wave (mmWave) band (for example, a <NUM> band) is being considered. To reduce path loss of radio waves and increase a transfer distance of radio waves in an ultra-high-frequency band, in <NUM> communication systems, technologies for beamforming, massive multiple input multiple output (massive MIMO), full dimensional MIMO (FD-MIMO), array antenna, analog beamforming, and large-scale antenna are being discussed, and applied to the NR system. Also, to improve the network of the system, various technologies, such as advanced small cell, cloud radio access network (cloud RAN), ultra-dense networks, device to device communication (D2D), wireless backhaul, moving networks, cooperative communication, coordinated multi-points (CoMP), and interference cancellation, have been developed for <NUM> communication systems. In addition, other technologies, such as hybrid frequency shift keying (FSK) and quadrature amplitude (QAM) modulation (FQAM) and sliding window superposition coding (SWSC) based on advanced coding modulation (ACM) and non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA) based on filter bank multi carrier (FBMC), have been developed for <NUM> communication systems.

Meanwhile, the Internet is evolving from a human-centered network in which humans generate and consume information to an Internet of Things (IoT) network in which distributed components such as objects transmit, receive, and process information. Internet of Everything (IoE) technology resulting from combining loT technology with big data processing technology, etc. through a connection to a cloud server or the like is on the rise. To implement the loT, various technical factors, such as sensing technology, wired/wireless communication, network infrastructure, service interface technology, and security technology, are required. Recently, technologies including a sensor network, machine to machine (M2M) communication, and machine type communication (MTC) for connections between objects have been studied. In an loT environment, an intelligent Internet technology (IT) service is provided to collect and analyze data generated by connected objects to create new value for human life. The loT may be applied to various fields, such as smart homes, smart buildings, smart cities, smart cars/connected cars, smart grids, health care, smart appliances, and advanced medical services, through convergence and combination between existing information technology (IT) and various industries.

Accordingly, various attempts to apply a <NUM> communication system to an loT network are being made. For example, technologies, such as sensor networks, M2M communication, and MTC, are implemented by technologies, such as beam forming, MIMO, and array antenna, which are <NUM> communication technologies. Applying a cloud radio access network (CRAN) as big data processing technology is also an example of the convergence of <NUM> technology and loT technology. With the development of mobile communication systems as described above, various services are being provided. Therefore, a method for effectively providing such services is required. <CIT> relates to a method and apparatus for performing retransmission processing. <CIT> relates to the field of processing <NUM> LTE 3rd Generation Partnership Project Online Charging System (3GPP OCS) usage records into Transferred Account Procedure (TAP) records that are received by <NUM>/<NUM> billing systems as visited network usage billing records. <CIT> discloses a method for preventing charging data losses in a mobile communication exchange is provided to store charging data in a buffer when data transmissions fail, after transmitting the charging data in the mobile communication exchange, to retransmit the charging data, or to output the charging data through a terminal, so as to prevent the charging data losses. <CIT> relates to a data charging method and system in a mobile communication network. <CIT> relates to a billing service system and method, a billing data processing device, and a method of operating the billing data processing device.

The disclosed embodiments provide an apparatus and method capable of effectively providing a service in a mobile communication system.

A method for billing in a wireless communication system, according to an embodiment, includes: transmitting billing data to an upper entity; determining whether the billing data has been normally transmitted; and executing a supplementary operation based on a result of the determining.

When the embodiments are described, descriptions about technical content well known in the technical field to which the disclosure belongs and not directly related to the disclosure will be omitted. The reason for this is to more clearly convey, without obscuring, the gist of the disclosure by omitting unnecessary descriptions.

For the same reason, some components of the accompanying drawings may be exaggeratedly shown, omitted, or schematically shown. Also, the sizes of the components do not completely reflect their actual sizes. The same or corresponding components in the drawings are assigned like reference numerals.

Advantages and features of the disclosure and a method for achieving them will be clear with reference to the accompanying drawings, in which embodiments are shown. The disclosure may, however, be embodied in many different forms and should not be construed as being limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the disclosure to those of ordinary skill in the art, and the disclosure is only defined by the scope of the claims. Like reference numerals denote like components throughout the specification.

It will be appreciated that the combinations of blocks and flowchart illustrations in the process flow diagrams may be performed by computer program instructions. These computer program instructions may be loaded into a processor of a general purpose computer, a special purpose computer, or other programmable data processing equipment, so that those instructions, which are executed through a processor of a computer or other programmable data processing equipment, create means for performing functions described in the flowchart block(s). These computer program instructions may also be stored in a computer-executable or computer-readable memory capable of directing a computer or other programmable data processing equipment to implement the functions in a particular manner so that the instructions stored in the computer-executable or computer-readable memory are also capable of producing manufacturing items containing instruction means for performing the functions described in the flowchart block(s). Computer program instructions may also be installed on a computer or other programmable data processing equipment so that a series of operating steps may be performed on a computer or other programmable data processing equipment to create a computer-executable process. Therefore, it is also possible for the instructions to operate the computer or other programmable data processing equipment to provide steps for executing the functions described in the flowchart block(s).

In addition, each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing specified logical function(s). It should also be noted that in some alternative implementations, the functions mentioned in the blocks may occur out of order. For example, two blocks shown in succession may actually be executed substantially concurrently, or the blocks may sometimes be performed in reverse order according to the corresponding function.

As used herein, the terms 'portion', 'module', or 'unit' refers to a unit that can perform at least one function or operation, and may be implemented as a software or hardware component such as a Field Programmable Gate Array (FPGA) or an Application Specific Integrated Circuit (ASIC). However, the term 'portion', 'module' or'unit' is not limited to software or hardware. The 'portion', 'module', or 'unit' may be configured in an addressable storage medium, or may be configured to run on at least one processor. Therefore, according to an embodiment of the disclosure, the 'portion', 'module', or 'unit' includes: components such as software components, object-oriented software components, class components, and task components; processes, functions, attributes, procedures, sub-routines, segments of program codes, drivers, firmware, microcodes, circuits, data, databases, data structures, tables, arrays, and variables. Functions provided in the components and 'portions', 'modules' or 'units' may be combined into a smaller number of components and 'portions', 'modules' and 'units', or subdivided into additional components and 'portions', 'modules' or 'units'. Also, the components and 'portions', 'modules' or 'units' may be configured to run on one or more Central Processing Units (CPUs) in a device or a security multimedia card. Also, in the embodiments, the 'portion', 'module' or 'unit' may include one or more processors.

In the following descriptions, the terms used to identify connected nodes, the terms indicating network entities, the terms indicating messages, the terms indicating interfaces between network objects, the terms indicating various identification information, etc. are examples for convenience of description. Accordingly, the disclosure is not limited to these terms, and other terms having the equivalent technical meaning may be used.

Hereinafter, for convenience of description, the disclosure uses terms and names defined in a <NUM>rd Generation Partnership Project Long Term Evolution (3GPP LTE) standard and/or a <NUM>rd Generation Partnership Project New Radio (3GPP NR) standard, or modified terms and names based on the terms and names. However, the disclosure is not limited to the terms and names, and may be applied in the same way to a system based on another standard. Also, in the disclosure, the term User Equipment (UE) may represent various wireless communication devices including mobile phones, NB-loT devices, and sensors.

<FIG> shows a structure of a LTE system according to an embodiment.

Referring to <FIG>, a radio access network of an LTE system may be configured with Evolved Nodes B (eNBs) (hereinafter, also referred to as Nodes B, LTE nodes, or base stations) 1a-<NUM>, 1a-<NUM>, 1a-<NUM>, and 1a-<NUM>, a Mobility Management Entity (MME) 1a-<NUM>, and a Serving-Gateway (S-GW) 1a-<NUM>. A User Equipment (UE) 1a-<NUM> may be connected to an external network through the ENBs 1a-<NUM>, 1a-<NUM>, 1a-<NUM>, and 1a-<NUM> and the S-GW 1a-<NUM>.

In <FIG>, the eNBs 1a-<NUM>, 1a-<NUM>, 1a-<NUM>, and 1a-<NUM> may correspond to Nodes B of a Universal Mobile Telecommunication System (UMTS). The eNBs 1a-<NUM>, 1a-<NUM>, 1a-<NUM>, and 1a-<NUM> may be connected to the UE 1a-<NUM> through a wireless channel, and perform more complicated functions than the nodes B. In the LTE system, because all user traffics including a real-time service such as Voice over IP (VoIP) are serviced through a shared channel, a device for performing scheduling by collecting status information of UEs, such as buffer statuses of UEs, available transmission power states of UEs, channel states of UEs, etc., is needed. The eNBs 1a-<NUM> to 1a-<NUM> may function as such a device. An eNB may generally control a plurality of cells. For example, to implement a transmission speed of <NUM> Mbps, the LTE system uses, as air interface technology, Orthogonal Frequency Division Multiplexing (OFDM), for example, in a bandwidth of <NUM>. Also, Adaptive Modulation & Coding (AMC) of determining a modulation scheme and a channel coding rate according to a channel state of a UE may be applied. The S-GW 1a-<NUM>, which is a device for providing data bearers, may generate or remove data bearers according to a control of the MME 1a-<NUM>. The MME 1a-<NUM> may be in charge of various control functions, as well as a mobility management function for UEs, and may be connected to a plurality of eNBs.

<FIG> shows a structure of a next-generation mobile communication system to which an embodiment is applied. Referring to <FIG>, a next generation mobile communication system (hereinafter, also referred to as a NR or a <NUM>th Generation (<NUM>) system) may include a <NUM> access network <NUM> and a <NUM> core network (CN) <NUM>. A UE <NUM> supporting a next-generation mobile communication system may communicate with a data network <NUM> through the <NUM> access network <NUM> and the <NUM> core network <NUM>.

The next-generation mobile communication system of <FIG> may support a plurality of radio access technologies. According to an embodiment, the next-generation mobile communication system may include a New Radio Node B (hereinafter, also referred to as gNB or NR Node B) supporting a first radio access technology and an eNB supporting the second radio access technology. In this case, both the gNB and eNB may support the UE <NUM>, and the eNB may use a <NUM> function.

According to an embodiment, the gNB may be used as a secondary node cooperating with the eNB to provide data transmission for the UE <NUM>. That is, the eNB may be used as a master node, and the gNB may be used as a secondary node. In this case, the eNB may configure the gNB, and perform data transmission to the UE <NUM> based on Dual Connectivity (DC). According to an embodiment, the gNB may be connected to a SGW through a User Plane (UP), without being connected to a MME.

<FIG> is a view for describing a protocol structure of a next-generation mobile communication system to which an embodiment is applied. Referring to <FIG>, the next-generation mobile communication system may include an eNB <NUM> and a gNB <NUM> connected to a core network <NUM>. According to an embodiment, the eNB <NUM> and the gNB <NUM> may be connected to the core network <NUM> through a S1 interface, and the eNB <NUM> may be connected to the gNB <NUM> through an X2 interface.

In the next-generation mobile communication system of <FIG>, various types of bearers may be used for data transmission. According to an embodiment, the bearers may include a split bearer, a Master Cell Group (MCG) bearer, or a Secondary Cell Group (SCG) bearer.

The split bearer may indicate that, when a master node, for example, the eNB <NUM> receives data from the core network <NUM>, a path for the data is split into two paths and thus the data is transmitted from the master node <NUM> to a UE via the one path and the data is transmitted from a secondary node, that is, the gNB <NUM> to the UE via the other path. The MCG bearer may indicate that, when the master node <NUM> receives data from the core network <NUM>, the data is transmitted from the master node <NUM> to the UE. The SCG bearer may indicate that, when the secondary node <NUM> receives data from the core network <NUM>, the data is transmitted from the secondary node <NUM> to the UE.

Main functions of Packet Data Convergence Protocol (PDCP) 311a, 311b, and <NUM> may include a part of the following functions.

Main functions of Radio Link Control (RLC) 312a, 312b, and <NUM> may include a part of the following functions.

Medium Access Control (MAC) <NUM> and <NUM> may be connected to several RLC layer devices, and main functions of the MAC <NUM> and <NUM> may include a part of the following functions.

Physical (PHY) layers <NUM> and <NUM> may perform an operation of performing channel coding and modulation on upper layer data to generate an OFDM symbol and transmitting the OFDM symbol through a wireless channel, or of performing demodulation and channel decoding on an OFDM symbol received through a wireless channel and transferring a result of the demodulation and channel decoding to an upper layer.

In the next-generation mobile communication system of <FIG> and <FIG>, the UE may perform a procedure of access to a wireless communication system (for example, a LTE system) supporting the second radio access technology through the eNB. At this time, the UE may transmit information about capability supporting the first radio access technology (for example, <NUM>) to a LTE eNB or a <NUM> eNB. According to another embodiment, UE information about capability supporting <NUM> may be transferred through UE subscription information (for example, International Mobile Equipment Identity (IMEI) or Aggregate maximum bitrate (AMBR)).

When the eNB <NUM> or gNB <NUM> identifies that the UE is a UE supporting <NUM>, the eNB <NUM> or gNB <NUM> may transmit <NUM> cell configuration information, <NUM> cell measurement configuration information, etc. to the UE. According to an embodiment, a <NUM> eNB and a gateway may set a <NUM> data bearer via which a <NUM> service can be provided to the UE. Thereafter, the UE may receive the <NUM> service from the <NUM> eNB via the <NUM> data bearer.

When the UE receives the <NUM> service, a Control Plane (CP) is performed by the eNB <NUM> which is a master node, and in a User Plane (UP) for user packet transmission, an IP address of the gNB <NUM> which is a secondary node is used. In this case, because a LTE core network, for example, a MME or Gateway (GW) knows only the IP address of the user plane, the LTE core network cannot identify a radio access technology of a specific user plane. That is, the LTE core network cannot identify which one of an eNB and a gNB the specific user plane is interworking with. Accordingly, in a next-generation mobile communication system based on Dual Connectivity supporting a plurality of radio access technologies, a packet being transmitted through the gNB <NUM> and a packet being transmitted through the eNB <NUM> may coexist in the same bearer.

To differentially apply billing for <NUM> being the first radio access technology and billing for a LTE system being the second radio access technology, the eNB <NUM> which is a master node may count packets through the gNB <NUM> to obtain billing data, and transfer the billing date to the GW through a Secondary Radio Access Technology (RAT) Data Usage IE. The GW may differentially apply billing for the <NUM> and billing for the LTE service based on the received billing data.

<FIG> is a view for describing a billing data transfer method according to an embodiment. Referring to <FIG>, billing data may be transferred from an eNB <NUM> to a GW <NUM> via a MME <NUM>.

In operation S411, billing data obtained by the eNB <NUM> may be transmitted from the eNB <NUM> to the MME <NUM>. After the eNB <NUM> transmits the billing data to the MME <NUM>, the eNB <NUM> may delete the billing data. The billing data may include RAT information, time/duration information, data volume information, etc. According to an embodiment, the billing data may include information such as [Table <NUM>] and [Table <NUM>] below.

In operation S421, the billing data may be transmitted from the MME <NUM> to the GW <NUM>. After the MME <NUM> transmits the billing data to the GW <NUM>, the MME <NUM> may delete the billing data.

Referring to <FIG>, because the billing data is transmitted from the eNB <NUM> to the GW <NUM> via the MME <NUM>, the GW <NUM> applies differential billing for <NUM> and billing for a LTE service based on the billing data. Meanwhile, while the billing data is transmitted, the billing data may be lost or an error may occur. Hereinafter, an enhanced billing data transfer method will be described with reference to the accompanying drawing.

<FIG> is a flowchart for describing a billing data transfer method of an entity according to an embodiment.

In operation S510, an entity transmits billing data to an upper entity. According to an embodiment, the entity is an eNB or MME. When the entity is an eNB, the billing data is transmitted to a MME which is an upper entity. When the entity is a MME, the billing data is transmitted to a GW which is an upper entity.

In operation S520, the entity determines whether the billing data has been normally transmitted. The billing data may be transmitted through various messages.

According to an embodiment, the billing data may be transmitted through a message for which a response message exists, among messages defined in the 3GPP standard. When a response message exists, the entity determines whether the upper entity has received the billing data based on information included in the response message, although the upper entity does not transmit any new message.

According to an embodiment, the billing data may be transmitted through a message for which no response message exists, among messages defined or not defined in the 3GPP standard. When no response message exists, the upper entity may transmit a new message representing whether or not the upper entity has received the billing data to the entity.

According to an embodiment, the upper entity may transmit a message representing whether or not billing data has been received to the entity, in unit of each bearer. However, to prevent excessive traffic, the upper entity may obtain and store a billing reception list in unit of each lower entity, not in unit of a bearer. The billing reception list may include information about a plurality of pieces of billing data. The upper entity may transmit a message based on the billing reception list to the entity at regular time intervals.

In operation S530, the entity performs a supplementary operation based on a result of the determining.

According to an embodiment, the supplementary operation may include an operation of deleting billing data that has been normally transmitted. According to an embodiment, the supplementary operation may include an operation of retransmitting billing data that has not been normally transmitted. Also, according to an embodiment, when there is billing data that has not been completely transmitted during a predefined time interval, the supplementary operation may include an operation of deleting the billing data that has failed to be transmitted, outputting a fault message, and storing the billing data that has failed to be transmitted and identification information of the billing data as a log. However, the supplementary operation according to the disclosure is not limited to the above-described embodiment.

<FIG> is a view for describing a billing data transfer method according to an embodiment. Referring to <FIG>, billing data may be transmitted from an eNB <NUM> to a GW <NUM> via a MME <NUM>.

In operation S611, the eNB <NUM> transmits the billing data to the MME <NUM>. The billing data may be transmitted through a message for which a response message exists among messages defined in the 3GPP standard. According to an embodiment, the eNB <NUM> may include the billing data in a message included in [Table <NUM>] below, and transmit the message.

In operation S621, when the MME <NUM> receives the billing data, the MME <NUM> transmits a response message including data representing successful reception of the billing data to the eNB <NUM>. The response message may be a response message for the message transmitted from the eNB <NUM>, defined in the 3GPP standard. According to an embodiment, the MME <NUM> may include the data representing successful reception of the billing data in a response message disclosed in [Table <NUM>] below, and transmit the response message to the eNB <NUM>.

In operation S612, when the eNB <NUM> receives the data representing successful reception of the billing data from the MME <NUM>, the eNB <NUM> determines that the billing data has been normally transmitted. At this time, the eNB <NUM> may delete the billing data stored therein.

In operation S622, the MME <NUM> may transmit the billing data to the GW <NUM>. The billing data may be transmitted through a message for which a response message exists among the messages defined in the 3GPP standard. According to an embodiment, the MME <NUM> may include the billing data in a message disclosed in [Table <NUM>] below, and transmit the message.

In operation S631, when the GW <NUM> receives the billing data, the GW <NUM> transmits a response message including data representing successful reception of the billing data to the MME <NUM>. The response message may be a response message for the message transmitted from the MME <NUM>, defined in the 3GPP standard. According to an embodiment, the GW <NUM> may include data representing successful reception of the billing data in the response message disclosed in [Table <NUM>], and transmit the response message to the MME <NUM>.

In operation S623, when the MME <NUM> receives the data representing successful reception of the billing data from the GW <NUM>, the MME <NUM> determines that the billing data has been normally transmitted. In this case, the MME <NUM> may delete the billing data stored therein.

In operation S711, the eNB <NUM> may transmit the billing data to the MME <NUM>. The billing data may be transmitted through a message for which no response message exists, among messages defined or not defined in the 3GPP standard. According to an embodiment, the eNB <NUM> may include the billing data in a message disclosed in [Table <NUM>] below, and transmit the message.

In operation S721, the MME <NUM> may obtain and store a billing reception list. The billing reception list may be a list storing billing data received from the eNB <NUM> and identification information related to the billing data, and may be managed in unit of a lower entity. For example, the MME <NUM> may receive billing data from a plurality of eNBs, and store billing data for the individual eNBs and identification information related to the billing data as a billing reception list. According to an embodiment, the billing reception list may include International Mobile Subscriber Identity (IMSI) and Evolved Packet System Bearer ID (EBID).

In operation S722, the MME <NUM> may transmit the billing reception list to the eNB <NUM>.

In the embodiment of <FIG>, because the eNB <NUM> has transmitted the billing data to the MME <NUM> through a message for which no response message exists, the MME <NUM> may need to transfer the billing reception list to the eNB <NUM> through a message of a new format. According to an embodiment, the MME <NUM> may transmit the billing reception list to the eNB <NUM> by using a MME Configuration Transfer message.

When a predefined event occurs, the MME <NUM> may transmit the billing reception list to the eNB <NUM>. According to an embodiment, the MME <NUM> may transmit the billing reception list to the eNB <NUM> at regular time intervals. A time at which the MME <NUM> transmits the billing reception list may depend on a communication environment. Alternatively, according to an embodiment, when a predefined amount of information is collected, the MME <NUM> may transmit the billing reception list to the eNB <NUM>.

Also, according to an embodiment, the MME <NUM> may transmit a part of the billing reception list to the eNB <NUM>. For example, because the MME <NUM> can manage a billing reception list in unit of a lower entity, the MME <NUM> may transmit only a billing reception list corresponding to the eNB <NUM> among stored billing reception lists to the eNB <NUM>.

In operation S712, the eNB <NUM> may delete the billing data based on the billing reception list received from the MME <NUM>. More particularly, the eNB <NUM> may delete billing data identified to have been normally transmitted among the billing data transmitted in operation S711, based on the billing reception list received from the MME <NUM>. That is, the eNB <NUM> may not delete billing data that does not exist in the billing reception list received from the MME <NUM>, among the billing data transmitted in operation S711.

In operation S723, the MME <NUM> transmits the billing data received from the eNB <NUM> to the GW <NUM>. The billing data may be transmitted through a message for which no response message exists, among the messages defined or not defined in the 3GPP standard. According to an embodiment, the MME <NUM> may transmit the billing data to the GW <NUM> through a Delete Bearer Response message.

In operation <NUM>, the GW <NUM> may obtain and store the billing reception list. The billing reception list may be a list storing billing data received from the MME <NUM> and identification information related to the billing data, and may be managed in unit of a lower entity. For example, the GW <NUM> may store billing data for individual MMEs and identification information related to the billing data as a billing reception list. According to an embodiment, the billing reception list may include IMSI and EBID.

In operation S732, the GW <NUM> transmits the billing reception list to the MME <NUM>.

The GW <NUM> may transmit the billing reception list to the MME <NUM> by using various messages. According to an embodiment, the GW <NUM> may transmit the billing reception list to the MME <NUM> by using an Echo Request message. Because the Echo Request message is a message being periodically transmitted from the GW <NUM> to the MME <NUM>, the GW <NUM> may transmit the billing reception list to the MME <NUM> without any additional traffic.

When a predefined event occurs, the GW <NUM> may transmit the billing reception list to the MME <NUM>. According to an embodiment, the GW <NUM> may transmit the billing reception list to the MME <NUM> at regular time intervals. A time at which the GW <NUM> transmits the billing reception list may depend on a communication environment. Alternatively, according to an embodiment, when a predefined amount of information is collected, the GW <NUM> may transmit the billing reception list to the MME <NUM>.

Also, according to an embodiment, the GW <NUM> may transmit a part of the billing reception list to the MME <NUM>. For example, because the GW <NUM> can manage a billing reception list in unit of a lower entity, the GW <NUM> may transmit only a billing reception list corresponding to the MME <NUM> among stored billing reception lists to the MME <NUM>.

In operation S724, the MME <NUM> may delete the billing data based on the billing reception list received from the GW <NUM>. More particularly, the MME <NUM> may delete billing data identified to have been normally transmitted among the billing data transmitted in operation S723, based on the billing reception list received from the GW <NUM>. That is, the MME <NUM> may not delete billing data that does not exist in the billing reception list received from the GW <NUM>, among the billing data transmitted in operation S723.

<FIG> is a view for describing a billing data transfer method according to an embodiment. According to an embodiment, <FIG> describes a billing data transfer method when a data bearer is maintained. According to an embodiment, a procedure in which a bearer is maintained may include a Connection Suspend Procedure, a S1 Release Procedure, an E-RAB Modification Procedure, a Handover Procedure without S-GW Relocation, a procedure of Usage Data Reporting for Secondary RAT, etc..

Referring to <FIG>, billing data may be transmitted from an eNB <NUM> to a GW <NUM> via a MME <NUM>. According to an embodiment, each entity may retransmit billing data when the billing data has failed to be normally transmitted.

In operation S811, the eNB <NUM> transmits the billing data to the MME <NUM>. The billing data may be transmitted through messages of various formats.

In operation S810, the eNB <NUM> may drive a timer. According to an embodiment, the eNB <NUM> may drive the timer simultaneously when transmitting the billing data in operation S811. Alternatively, the eNB <NUM> may drive the timer after transmitting the billing data. Start and expiration times of the timer may be set by using various criteria. The timer that is driven by the eNB <NUM> may be temporal criterion for maintaining a retransmission list which will be described later.

The timer may be driven in various units. According to an embodiment, the timer may be driven for each target UE of billing data. Alternatively, the timer may be driven for each piece of billing data.

In operation S812, the eNB <NUM> may store a retransmission list. The retransmission list may be a list storing the billing data transmitted from the eNB <NUM> to the MME <NUM> in operation S811 and identification information related to the billing data. According to an embodiment, the retransmission list may be managed in unit of a UE or in unit of an upper entity. For example, the eNB <NUM> may store billing data and identification information related to the billing data for each eNB which is transmitting the billing data, as a retransmission list. According to an embodiment, the retransmission list may include IMSI and EBID.

In operation S821, the MME <NUM> transmits a response message to the eNB <NUM>. The response message may represent billing data successfully received by the MME <NUM> among the billing data transmitted from the eNB <NUM> to the MME <NUM> in operation S811.

According to an embodiment, when the eNB <NUM> transmits the billing data through a message for which a response message exists among the messages defined in the 3GPP standard, the MME <NUM> may transmit data representing successful reception of the billing data, as a response message, to the eNB <NUM>, by using a response message for the message transmitted from the eNB <NUM>, the response message defined in the 3GPP standard.

According to another embodiment, when the eNB <NUM> transmits the billing data through a message for which no response message exists, among messages defined or not defined in the 3GPP standard, the MME <NUM> may transmit data representing successful reception of the billing data as a response message to the eNB <NUM> through a message of a new format.

According to an embodiment, the MME <NUM> may obtain and store a billing reception list. The billing reception list may be a list storing billing data received from the eNB <NUM> and identification information related to the billing data, and may be managed in unit of a lower entity. When the MME <NUM> receives a plurality of pieces of billing data, the MME <NUM> may transmit a billing reception list for the plurality of pieces of billing data as a response message, instead of transmitting all response messages for the respective pieces of billing data.

According to an embodiment, when a predefined event occurs, the MME <NUM> transmits a response message to the eNB <NUM>. According to an embodiment, the MME <NUM> may transmit a response message to the eNB <NUM> at regular time intervals. A time at which the MME <NUM> transmits the response message may depend on a communication environment. Alternatively, according to an embodiment, when a predefined amount of information is collected, the MME <NUM> may transmit the response message to the eNB <NUM>.

Also, according to an embodiment, the MME <NUM> may transmit a part of the billing reception list as a response message to the eNB <NUM>. For example, because the MME <NUM> can manage a billing reception list in unit of a lower entity, the MME <NUM> may transmit only a billing reception list corresponding to the eNB <NUM> among stored billing reception lists to the eNB <NUM>.

In operation S813, the eNB <NUM> may update the retransmission list based on the response message received from the MME <NUM>. According to an embodiment, the eNB <NUM> may identify data successfully transmitted to the MME <NUM> among a plurality of pieces of billing data transmitted in operation S811, based on the response message. The eNB <NUM> may delete data about the successfully transmitted billing data from the retransmission list, and leave billing data identified to have failed to be transmitted.

In operation S814, the eNB <NUM> may retransmit the billing data to the MME <NUM>. The eNB <NUM> may retransmit only the billing data identified to have failed to be transmitted, based on the retransmission list.

When a predefined event occurs, the eNB <NUM> may perform a retransmission operation. According to an embodiment, the eNB <NUM> may retransmit the billing data to the MME <NUM> at regular time intervals. In this case, the eNB <NUM> may retransmit the billing data by using a message defined to be periodically transmitted, for example, an ENB Configuration message. Alternatively, according to an embodiment, when a predefined amount of information is collected in the retransmission list, the eNB <NUM> may retransmit the billing data to the MME <NUM>.

In operation S815, the timer driven in operation S810 may be expired.

In operation S816, the eNB <NUM> may delete the retransmission list based on the expiration of the timer, and execute a subsequent operation.

According to an embodiment, the eNB <NUM> may delete billing data corresponding to an expired timer and information related to the billing data from the retransmission list, based on a plurality of timers driven. Because continuously retransmitting billing data without limit is inefficient, the eNB <NUM> may stop retransmitting data that has continuously failed to be retransmitted, by using a timer.

Meanwhile, the eNB <NUM> may output a fault message for the billing data deleted from the retransmission list based on the expiration of the timer. The eNB <NUM> may output the fault message to report a user or a network manager that a problem related to billing has occurred. Also, the eNB <NUM> may store the billing data deleted from the retransmission list based on the expiration of the timer and identification information related to the billing data, as a log. The eNB <NUM> may provide the information stored as the log in response to a subsequent request.

In operation S822, the MME <NUM> may transmit the billing data to the GW <NUM>. The billing data may be transmitted through messages of various formats.

In operation S820, the MME <NUM> may drive a timer. According to an embodiment, the MME <NUM> may drive the timer simultaneously when transmitting the billing data in operation S822. Alternatively, the MME <NUM> may drive the timer after transmitting the billing data. Start and expiration times of the timer may be set by using various criteria. The timer that is driven by the MME <NUM> may be temporal criterion for maintaining a retransmission list stored in the MME <NUM>.

The timer may be driven in various units. According to an embodiment, the timer may be driven for each target UE of billing data. Alternatively, the timer may be driven for each billing data.

In operation S823, the MME <NUM> may store a retransmission list. The retransmission list may be a list storing billing data transmitted from the MME <NUM> to the GW <NUM> in operation S822 and identification information related to the billing data. According to an embodiment, the retransmission list may be managed in unit of a lower entity or an upper entity. According to an embodiment, the retransmission list may include IMSI and EBID.

In operation S831, the GW <NUM> transmits a response message to the MME <NUM>. The response message may represent billing data successfully received by the GW <NUM> among the billing data transmitted from the MME <NUM> to the GW <NUM> in operation S822.

According to an embodiment, when the MME <NUM> transmits the billing data through a message for which a response message exists among the messages defined in the 3GPP standard, the GW <NUM> may transmit data representing successful reception of the billing data, as a response message, to the MME <NUM>, by using a response message for the message transmitted from the MME <NUM>, the response message defined in the 3GPP standard.

According to another embodiment, when the MME <NUM> transmits the billing data through a message for which no response message exists, among messages defined or not defined in the 3GPP standard, the GW <NUM> may transmit data representing successful reception of the billing data to the MME <NUM> by, as a response message, defining a message of a new format or using a message determined in advance to be periodically transmitted to the MME <NUM> among predefined messages.

According to an embodiment, the GW <NUM> may obtain and store a billing reception list. The billing reception list may be a list storing billing data received from the MME <NUM> and identification information related to the billing data, and may be managed in unit of a lower entity. When the GW <NUM> receives a plurality of pieces of billing data, the GW <NUM> may transmit a billing reception list for the plurality of pieces of billing data as a response message, instead of transmitting all response messages for the respective pieces of billing data.

According to an embodiment, when a predefined event occurs, the GW <NUM> may transmit a response message to the MME <NUM>. According to an embodiment, the GW <NUM> may transmit a response message to the MME <NUM> at regular time intervals. A time at which the GW <NUM> transmits the response message may depend on a communication environment. Alternatively, according to an embodiment, when a predefined amount of information is collected, the GW <NUM> may transmit the billing reception list to the MME <NUM>.

Also, according to an embodiment, the GW <NUM> may transmit a part of the billing reception list, as a response message, to the MME <NUM>. For example, because the GW <NUM> can manage a billing reception list in unit of a lower entity, the GW <NUM> may transmit only a billing reception list corresponding to the MME <NUM> among stored billing reception lists to the MME <NUM>.

In operation S824, the MME <NUM> may update the retransmission list based on the response message received from the GW <NUM>. According to an embodiment, the MME <NUM> may identify data successfully transmitted to the GW <NUM> among a plurality of pieces of billing data transmitted in operation S822, based on the response message. The MME <NUM> may delete data about the successfully transmitted billing data from the retransmission list, and leave billing data identified to have failed to be transmitted.

In operation S832, the MME <NUM> may retransmit the billing data to the GW <NUM>. The MME <NUM> may retransmit only the billing data identified to have failed to be transmitted, based on the retransmission list.

When a predefined event occurs, the MME <NUM> may perform a retransmission operation. According to an embodiment, the MME <NUM> may retransmit the billing data to the GW <NUM> at regular time intervals. In this case, the MME <NUM> may retransmit the billing data by using a message defined to be periodically transmitted, for example, an Echo Request message. Alternatively, according to an embodiment, when a predefined amount of information is collected in the retransmission list, the MME <NUM> may retransmit the billing data to the GW <NUM>.

In operation S825, the timer driven in operation S820 may be expired.

In operation S826, the MME <NUM> may delete the retransmission list based on the expiration of the timer, and execute a subsequent operation.

According to an embodiment, the MME <NUM> may delete billing data corresponding to an expired timer and information related to the billing data from the retransmission list, based on a plurality of timers driven. Because continuously retransmitting billing data without limit is inefficient, the MME <NUM> may stop retransmitting data that has continuously failed to be retransmitted, by using a timer.

Meanwhile, the MME <NUM> may output a fault message for the billing data deleted from the retransmission list based on the expiration of the timer. The MME <NUM> may output the fault message to report a user or a network manager that a problem related to billing has occurred. Also, the MME <NUM> may store the billing data deleted from the retransmission list based on the expiration of the timer and identification information related to the billing data, as a log. The MME <NUM> may provide the information stored as the log in response to a subsequent request.

<FIG> is a view for describing a billing data transfer method according to an embodiment. <FIG> describes a billing data transfer method when a data bearer is deleted. According to an embodiment, a procedure in which a bearer is deleted may include Detach, Bearer Deactivation, PDN Disconnection, Handover Procedure with S-GW Relocation, MME Triggered S-GW Relocation, etc..

Referring to <FIG>, billing data may be transmitted from an eNB <NUM> to a GW <NUM> via a MME <NUM>. According to an embodiment, each entity may retransmit billing data not normally stored, although a bearer is deleted.

In operation S911, the eNB <NUM> may transmit the billing data to the MME <NUM>. The billing data may be transmitted through messages of various formats.

In operation S910, the eNB <NUM> may drive a timer. According to an embodiment, the eNB <NUM> may drive the timer simultaneously when transmitting the billing data in operation S911. Alternatively, the eNB <NUM> may drive the timer after transmitting the billing data. Start and expiration times of the timer may be set by using various criteria. The timer that is driven by the eNB <NUM> may be temporal criterion for maintaining a retransmission list. The timer may be driven in various units. According to an embodiment, the timer may be driven for each target UE of billing data. Alternatively, the timer may be driven for each billing data.

In operation S912, the eNB <NUM> may store a retransmission list. The retransmission list may be a list storing the billing data transmitted from the eNB <NUM> to the MME <NUM> in operation S911 and identification information related to the billing data. According to an embodiment, the retransmission list may be managed in unit of a UE or in unit of an upper entity. For example, the eNB <NUM> may store billing data and identification information related to the billing data, as a retransmission list, for each eNB which is transmitting billing data. According to an embodiment, the retransmission list may include IMSI and EBID.

Meanwhile, when a deletion event for a bearer occurs, the eNB <NUM> may perform a procedure of deleting the bearer. While the eNB <NUM> deletes the bearer for which the deletion event has occurred, the eNB <NUM> may store billing data and identification information for the bearer in the retransmission list to maintain the billing data and identification information.

In operation S921, the MME <NUM> transmits a response message to the eNB <NUM>. The response message may represent billing data successfully received by the MME <NUM> among the billing data transmitted from the eNB <NUM> to the MME <NUM> in operation S911. According to an embodiment, the MME <NUM> may obtain and store a billing reception list. The billing reception list may be a list storing billing data received from the eNB <NUM> and identification information related to the billing data, and may be managed in unit of a lower entity. When the MME <NUM> receives a plurality of pieces of billing data, the MME <NUM> may transmit a billing reception list for the plurality of pieces of billing data as a response message, instead of transmitting all response messages for the respective pieces of billing data.

According to an embodiment, when a predefined event occurs, the MME <NUM> may transmit a response message to the eNB <NUM>. According to an embodiment, the MME <NUM> may transmit a response message to the eNB <NUM> at regular time intervals. A time at which the MME <NUM> transmits the response message may depend on a communication environment. Alternatively, according to an embodiment, when a predefined amount of information is collected, the MME <NUM> may transmit the response message to the eNB <NUM>.

In operation S913, the eNB <NUM> may update the retransmission list based on the response message received from the MME <NUM>. According to an embodiment, the eNB <NUM> may identify data successfully transmitted to the MME <NUM> among a plurality of pieces of billing data transmitted in operation S911, based on the response message. The eNB <NUM> may delete data about the successfully transmitted billing data from the retransmission list, and leave billing data identified to have failed to be transmitted.

In operation S914, the eNB <NUM> may retransmit the billing data to the MME <NUM>. The eNB <NUM> may retransmit only the billing data identified to have failed to be transmitted, based on the retransmission list.

In operation S915, the timer driven in operation S910 may be expired.

In operation S916, the eNB <NUM> may delete the retransmission list based on the expiration of the timer, and execute a subsequent operation.

In operation S922, the MME <NUM> may transmit the billing data to the GW <NUM>. The billing data may be transmitted through messages of various formats.

In operation S920, the MME <NUM> may drive a timer. According to an embodiment, the MME <NUM> may drive the timer simultaneously when transmitting the billing data in operation S922. Alternatively, the MME <NUM> may drive the timer after transmitting the billing data. Start and expiration times of the timer may be set by using various criteria. The timer that is driven by the MME <NUM> may be temporal criterion for maintaining a retransmission list stored in the MME <NUM>.

In operation S923, the MME <NUM> may store a retransmission list. The retransmission list may be a list storing the billing data transmitted from the MME <NUM> to the GW <NUM> in operation S922 and identification information related to the billing data. According to an embodiment, the retransmission list may be managed in unit of a lower entity or an upper entity. According to an embodiment, the retransmission list may include IMSI and EBID.

Meanwhile, when a deletion event for a bearer occurs, the MME <NUM> may perform a procedure of deleting the bearer. While the MME <NUM> deletes the bearer for which the deletion event has occurred, the MME <NUM> may store billing data and identification information for the bearer in the retransmission list to maintain the billing data and identification information.

In operation S931, when a deletion event for a bearer occurs, the GW <NUM> may perform a procedure of deleting the bearer. According to an embodiment, the GW <NUM> may determine whether a UE connected to the bearer is a UE that can use <NUM> based on Dual Connectivity (DC), by using Dual Connectivity with NR (DCNR) of a UP Function Selection Indication Flag of a Create Session Request message. When a bearer deletion event for a UE that can use <NUM> occurs, the GW <NUM> may execute the following procedure.

In operation S930, the GW <NUM> may drive a timer. The timer may be temporal criterion based on which the GW <NUM> maintains the bearer for which the deletion event has occurred. While the GW <NUM> performs a procedure of deleting the bearer for which the deletion event has occurred, the GW <NUM> may maintain the bearer therein until the timer is expired.

In operation S932, the GW <NUM> transmits a response message to the MME <NUM>. The response message may represent billing data successfully received by the GW <NUM> among the billing data transmitted from the MME <NUM> to the GW <NUM> in operation S922.

According to an embodiment, the GW <NUM> may obtain and store a billing reception list. The billing reception list may be a list storing billing data received from the MME <NUM> and identification information related to the billing data, and may be managed in unit of a lower entity. When the GW <NUM> receives a plurality of pieces of billing data, the MME <NUM> may transmit a billing reception list for the plurality of pieces of billing data as a response message, instead of transmitting all response messages for the respective pieces of billing data.

According to an embodiment, when a predefined event occurs, the GW <NUM> may transmit a response message to the MME <NUM>. According to an embodiment, the GW <NUM> may transmit a response message to the MME <NUM> at regular time intervals. A time at which the GW <NUM> transmits the response message may depend on a communication environment. According to an embodiment, when a predefined amount of information is collected, the GW <NUM> may transmit the response message to the MME <NUM>.

Also, according to an embodiment, the GW <NUM> may transmit a part of the billing reception list as a response message to the MME <NUM>. For example, because the GW <NUM> can manage a billing reception list in unit of a lower entity, the GW <NUM> may transmit only a billing reception list corresponding to the MME <NUM> among stored billing reception lists to the MME <NUM>.

In operation S924, the MME <NUM> may update the retransmission list based on the response message received from the GW <NUM>. According to an embodiment, the MME <NUM> may identify data successfully transmitted to the MME <NUM> among a plurality of pieces of billing data transmitted in operation S922, based on the response message. The MME <NUM> may delete data about the successfully transmitted billing data from the retransmission list, and leave billing data identified to have failed to be transmitted.

In operation S925, the MME <NUM> may retransmit the billing data to the GW <NUM>. The MME <NUM> may retransmit only the billing data identified to have failed to be transmitted, based on the retransmission list.

In operation S926, the timer driven in operation S920 may be expired.

In operation S927, the MME <NUM> may delete the retransmission list based on the expiration of the timer, and execute a subsequent operation.

In operation S933, the timer driven by the GW <NUM> in operation S930 may be expired.

In operation S934, the GW <NUM> may delete a bearer for which a deletion event occurs. When the bearer is deleted from the GW <NUM>, a billing operation may be not processed even when billing data for the corresponding bearer is received. However, according to an embodiment, when the timer driven by the GW <NUM> is set to a longer time than a timer driven by a lower entity for maintaining a retransmission list, no billing data for a bearer may be received after the bearer is deleted.

<FIG> shows a base station according to an embodiment. Referring to <FIG>, a base station <NUM> may include a processor <NUM>, a transceiver <NUM>, and a memory <NUM>. The base station <NUM> may correspond to an eNB 1a-<NUM>, 1a-<NUM>, 1a-<NUM>, or 1a-<NUM> illustrated in <FIG>. The transceiver <NUM>, the memory <NUM>, and the processor <NUM> of the base station <NUM> may operate according to a communication method of the base station <NUM> as described above. However, components of the base station <NUM> are not limited to the above-mentioned examples. For example, the base station <NUM> may be configured with more components than those described above or with less components than those descried above. Also, the transceiver <NUM>, the memory <NUM>, and the processor <NUM> may be implemented in a form of a chip.

The processor <NUM> may control a series of processes such that the base station <NUM> operates according to the above-described embodiments of the disclosure. The processor <NUM> according to an embodiment of the disclosure transmits billing data to an upper entity, determines whether the billing data has been normally transmitted, and executes a supplementary operation based on a result of the determining.

The transceiver <NUM> may transmit/receive a signal to/from an UE or another entity. For this, the transceiver <NUM> may be configured with an RF transmitter for up-converting and amplifying a frequency of a signal to be transmitted, an RF receiver for low-noise amplifying a received signal and down-converting a frequency of the received signal, etc. However, the RF transmitter and RF receiver are an embodiment of the transceiver <NUM>, and components of the transceiver <NUM> are not limited to the RF transmitter and the RF receiver.

Also, the transceiver <NUM> may receive a signal through a wireless channel, output the signal to the processor <NUM>, and transmit a signal output from the processor <NUM> through the wireless channel.

The memory <NUM> may store programs and data required for operations of the base station <NUM>. Also, the memory <NUM> may store control information or data included in a signal obtained by the base station <NUM>. The memory <NUM> may be configured with storage media, such as read only memory (ROM), random access memory (RAM), a hard disc, compact disc-read only memory (CD-ROM), and a digital versatile disc (DVD), or a combination of the storage media. Also, the memory <NUM> may be configured with a plurality of memories. According to an embodiment, the memory <NUM> may store a program for supporting beam-based cooperative communication.

<FIG> shows an internal structure of a gateway according to an embodiment. Referring to <FIG>, a gateway <NUM> may include a processor <NUM>, a transceiver <NUM>, and a memory <NUM>. However, components of the gateway <NUM> are not limited to the above-mentioned examples. For example, the gateway <NUM> may be configured with more components than those described above or with less components than those descried above. Also, the transceiver <NUM>, the memory <NUM>, and the processor <NUM> may be implemented in a form of a chip. Also, the gateway <NUM> and other network entities may be integrated into one body.

The processor <NUM> may control a series of processes such that the gateway <NUM> operates according to the above-described embodiments of the disclosure. According to an embodiment, the processor <NUM> may drive a timer based on a deletion event for a bearer, receive billing data of the bearer from a lower entity, and delete the bearer when the timer is expired.

The transceiver <NUM> may transmit/receive a signal to/from other entities. For this, the transceiver <NUM> may be configured with an RF transmitter for up-converting and amplifying a frequency of a signal to be transmitted, an RF receiver for low-noise amplifying a received signal and down-converting a frequency of the received signal, etc. However, the RF transmitter and RF receiver are an embodiment of the transceiver <NUM>, and components of the transceiver <NUM> are not limited to the RF transmitter and the RF receiver.

Also, the transceiver <NUM> may receive a signal through a wired or wireless channel, output the signal to the processor <NUM>, and transmit a signal output from the processor <NUM> through the wired or wireless channel.

The memory <NUM> may store programs and data required for operations of the gateway <NUM>. Also, the memory <NUM> may store control information or data included in a signal obtained by the gateway <NUM>. The memory <NUM> may be configured with storage media, such as ROM, RAM, a hard disc, CD-ROM, and a DVD, or a combination of the storage media. Also, the memory <NUM> may be configured with a plurality of memories. According to an embodiment, the memory <NUM> may store a program for supporting beam-based cooperative communication.

The methods according to the embodiments of the disclosure described in claims or specification thereof may be implemented in hardware, software, or a combination of hardware and software.

When the methods are implemented in software, a computer-readable storage medium storing at least one program (software module) may be provided. The at least one program stored in the computer-readable storage medium may be configured for execution by at least one processor within an electronic device. The at least one program may include instructions that cause the electronic device to execute the methods according to the embodiments of the disclosure described in the claims or specification thereof.

The program (software module or software) may be stored in RAM, a non-volatile memory including a flash memory, ROM, an electrically erasable programmable ROM (EEPROM), a magnetic disc storage device, CD-ROM, DVDs or other types of optical storage devices, and a magnetic cassette. Alternatively, the program may be stored in a memory that is configured as a combination of some or all of the memories. Also, a plurality of such memories may be included.

Furthermore, the program may be stored in an attachable storage device that may be accessed through communication networks such as the Internet, Intranet, a local area network (LAN), a wide LAN (WLAN), and a storage area network (SAN) or a communication network configured in a combination thereof. The storage device may access a device performing the embodiments of the disclosure through an external port. Further, a separate storage device on the communication network may also access the device performing the embodiments of the disclosure.

Claim 1:
A method, performed by an entity, of transmitting billing data for user equipment, UE, in a wireless communication system based on dual connectivity, DC, supporting a plurality of radio access technologies, the method comprising:
transmitting (S510), to an upper entity, billing data to differentially apply billing for <NUM> service and <NUM> service
determining (S520) whether the billing data has been normally transmitted; and
executing (S530) a supplementary operation based on a result of the determining,
wherein the entity is an eNB or a MME, wherein when the entity is an eNB, a MME is the upper entity, and when the entity is a MME, a GW is the upper entity,
wherein the UE connected to the eNB and a gNB,
wherein the eNB is master node and the gNB is secondary node,
wherein the executing of the supplementary operation comprises deleting the billing data in case that the billing data has been normally transmitted,
wherein the executing of the supplementary operation comprises: outputting a failure message based on a retransmission list; and
storing billing data that has failed to be normally transmitted among the billing data, as a log, based on the retransmission list,
wherein the determining of whether the billing data has been normally transmitted comprises:
receiving a response message representing reception of the billing data from the upper entity; and
determining whether the billing data has been normally transmitted, based on the response message.