Terminal device and method

Abstract

A terminal device communicates with a base station device, the terminal device comprising: a receiving unit, receiving an RRC message including an EHC setting from the base station device; and a processing unit, setting an EHC protocol according to the EHC setting, and attaching a context identifier to data during processing of the EHC protocol. When the value of the context identifier is a specific value, it indicates that Ethernet header compression is not applied to the Ethernet header of the data.

Description

Technical Field

[0001] The present invention relates to a terminal device and a method.

[0002] This application claims priority from Japanese Patent Application No. 2019-147899 filed in Japan on August 9, 2019, the contents of which are incorporated herein by reference. Background Art

[0003] The 3rd Generation Partnership Project (3GPP) is researching wireless access methods for cellular mobile communications, wireless networks (hereinafter referred to as "Long Term Evolution (LTE: registered trademark)" or "Evolved Universal Terrestrial Radio Access (EUTRA)"), and core networks (hereinafter referred to as "Evolved Packet Core (EPC)"). EUTRA is also known as E-UTRA.

[0004] Furthermore, 3GPP is conducting technical research and standardization for LTE-Advanced Pro, an extension of LTE, and NR (New Radio Technology), a new radio access technology, as wireless access methods and wireless network technologies for fifth-generation cellular systems (Non-Patent Document 1). Furthermore, research is also underway on 5GC (5th Generation Core Network), the core network for fifth-generation cellular systems (Non-Patent Document 2).

[0005] Furthermore, as one of the standards for local area networks, Ethernet (registered trademark) is standardized by the IEEE (Institute of Electrical and Electronics Engineers) 802 Committee.

[0006] Prior art literature

[0007] Non-patent literature

[0008] Non-Patent Document 1: 3GPP RP-170855, “Work Item on New Radio (NR) Access Technology”

[0009] Non-Patent Document 2: 3GPP TS 23.501 v15.3.0, “System Architecture for the 5G System; Stage 2”

[0010] Non-patent document 3: 3GPP TS 36.300, v15.3.0, "Evolved Universal Terestrial Radio Access (E-UTRA) and Evolved Universal Terestrial Radio Access Network (E-UTRAN); Overall description; Stage 2"

[0011] Non-Patent Document 4: 3GPP TS 36.331 v15.4.0, “Evolved Universal Terestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specifications”

[0012] Non-Patent Document 5: 3GPP TS 36.323 v15.3.0, “Evolved Universal Terestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification”

[0013] Non-Patent Document 6: 3GPP TS 36.322 v15.3.0, “Evolved Universal Terestrial Radio Access (E-UTRA); Radio Link Control (RLC) protocol specification”

[0014] Non-Patent Document 7: 3GPP TS 36.321 v15.3.0, “Evolved Universal Terestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification”

[0015] Non-Patent Document 8: 3GPP TS 37.340 v15.3.0, “Evolved Universal Terestrial Radio Access (E-UTRA) and NR; Multi-Connectivity; Stage 2”

[0016] Non-Patent Document 9: 3GPP TS 38.300 v15.3.0, “NR; NR and NG-RAN Overall Description; Stage 2”

[0017] Non-Patent Document 10: 3GPP TS 38.331 v15.4.0, “NR; Radio Resource Control (RRC); Protocol specifications”

[0018] Non-Patent Document 11: 3GPP TS 38.323 v15.3.0, “NR; Packet Data Convergence Protocol (PDCP) specification”

[0019] Non-Patent Document 12: 3GPP TS 38.322 v15.3.0, “NR; Radio Link Control (RLC) protocol specification”

[0020] Non-Patent Document 13: 3GPP TS 38.321 v15.3.0, “NR; Medium Access Control (MAC) protocol specification”

[0021] Non-Patent Document 14: 3GPP TS 23.401 v15.0.0, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access"

[0022] Non-Patent Document 15: 3GPP TS 23.502 v15.3.0, “Procedure for 5G System; Stage 2”

[0023] Non-Patent Document 16: 3GPP TS 37.324 v15.1.0, “NR; Service Data Adaptation Protocol (SDAP) specification”

[0024] Non-Patent Document 17: 3GPP RP-190728, “New WID: Support of NR Industrial Internet of Things (IoT)”

[0025] Non-Patent Document 18: 3GPP Draft_RAN2_106_Report_v3, “Report of 3GPP TSG RANWG2 meeting #106” https: / / www.3gpp.org / ftp / tsg_ran / WG2_RL2 / TSGR2_106 / Report / Draft_RAN2_106_Report_v3.zip

[0026] Non-Patent Document 19: IEEE 802.1Q-2014 - IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks. Summary of the Invention

[0027] Problems to be solved by the invention

[0028] Research into NR technologies is underway to expand existing NR technologies into the Industrial Internet of Things (IIoT). (Non-Patent Document 17) This research includes Ethernet header compression technology, which aims to reduce the overhead of Ethernet headers on data, assuming that Ethernet frames will be transmitted and received using NR.

[0029] Research is underway to achieve Ethernet header compression by associating an identifier called a context identifier with Ethernet header information and using the context identifier for all Ethernet header information (Non-Patent Document 18). However, detailed terminal operations for efficiently controlling data transmission and reception have not yet been studied.

[0030] One aspect of the present invention has been made in view of the above-mentioned problems, and one object of the present invention is to provide a terminal device and method capable of efficiently controlling the transmission and reception of data.

[0031] Technical Solution

[0032] To achieve the above-mentioned objective, one embodiment of the present invention adopts the following embodiment: a terminal device communicating with a base station device, comprising: a receiving unit configured to receive an RRC message from the base station device; and a processing unit configured to, upon receipt of a context identifier for a released context included in the RRC message, delete the context identifier and a context associated with the context identifier.

[0033] In addition, one embodiment of the present invention is a terminal device that communicates with a base station device, comprising: a receiving unit that receives an RRC message from the base station device; and a processing unit that, based on the fact that the RRC message includes information for setting a context management timer, generates a first context related to a header included in the first service data unit when a first service data unit is received from an upper layer, and starts or restarts a first timer for the first context when the first context related to the header included in the first service data unit is not stored; starts or restarts the first timer when the first context related to the header included in the first service data unit is stored, and deletes the first context based on the expiration of the first timer.

[0034] In addition, one embodiment of the present invention is a terminal device that communicates with a base station device, comprising: a receiving unit that receives an RRC message from the base station device; and a processing unit that, based on the fact that the RRC message includes information for setting a context management timer, generates a second context related to a header included in the second protocol data unit when a second protocol data unit is received from a lower layer, and starts or restarts a second timer for the second context when the second protocol data unit includes information indicating that header compression is not performed on the second protocol data unit, starts or restarts the second timer when the RRC message includes information indicating that header compression is performed on the second protocol data unit, and deletes the second context based on the expiration of the second timer.

[0035] In addition, one embodiment of the present invention is a terminal device that communicates with a base station device, has a processing unit, receives an RRC message including a maximum value of a context identifier from the base station device, and when a third service data unit is received from an upper layer, when a third context related to a header included in the third service data unit is not stored and the number of stored contexts reaches the maximum value of the context identifier, assigns a fourth context identifier associated with one of the stored contexts to the third context.

[0036] In addition, one embodiment of the present invention is a base station device that communicates with a terminal device, comprising: a sending unit that sends an RRC message to the terminal device; and a processing unit that causes the terminal device to perform processing to delete the context identifier and the context associated with the context identifier based on the context identifier of the released context included in the RRC message.

[0037] In addition, one embodiment of the present invention is a base station device that communicates with a terminal device, comprising: a sending unit that sends an RRC message to the terminal device; and a processing unit that enables the terminal device to perform processing based on the information for setting a context management timer included in the RRC message. When a first service data unit is received from an upper layer, if the first context related to the header included in the first service data unit is not stored, the terminal device generates a first context related to the header included in the first service data unit, starts or restarts a first timer for the first context, and starts or restarts the first timer when the first context related to the header included in the first service data unit is stored, and deletes the first context based on the expiration of the first timer.

[0038] In addition, one embodiment of the present invention is a base station device that communicates with a terminal device, comprising: a sending unit that sends an RRC message to the terminal device; and a processing unit that causes the terminal device to perform processing based on the fact that the RRC message includes information for setting a context management timer. When a second protocol data unit is received from a lower layer, the terminal device generates a second context related to a header included in the second protocol data unit, starts or restarts a second timer for the second context, starts or restarts the second timer, and deletes the second context based on the expiration of the second timer.

[0039] In addition, one embodiment of the present invention is a base station device that communicates with a terminal device, comprising a processing unit that sends an RRC message including a maximum value of a context identifier to the terminal device, so that the terminal device, when receiving a third service data unit from an upper layer, assigns a fourth context identifier associated with one of the stored contexts to the third context when a third context related to a header included in the third service data unit is not stored and the number of stored contexts reaches the maximum value of the context identifier.

[0040] In addition, an embodiment of the present invention is a method for a terminal device communicating with a base station device, wherein an RRC message is received from the base station device, and based on the fact that the RRC message includes a context identifier of a released context, the context identifier and the context associated with the context identifier are deleted.

[0041] In addition, one embodiment of the present invention is a method for a terminal device communicating with a base station device, wherein an RRC message is received from the base station device, and based on the fact that the RRC message includes information for setting a context management timer, when a first service data unit is received from an upper layer, a first context related to a header included in the first service data unit is generated without storing a first context related to the header included in the first service data unit, and a first timer for the first context is started or restarted; when the first context related to the header included in the first service data unit is stored, the first timer is started or restarted, and the first context is deleted based on the expiration of the first timer.

[0042] In addition, one embodiment of the present invention is a method for a terminal device communicating with a base station device, wherein an RRC message is received from the base station device, and based on the fact that the RRC message includes information for setting a context management timer, when a second protocol data unit is received from a lower layer, a second context related to a header included in the second protocol data unit is generated, and a second timer for the second context is started or restarted when the information indicating that the header compression of the second protocol data unit is included is included, and the second timer is started or restarted when the information indicating that the header compression of the second protocol data unit is included is included, and the second context is deleted based on the expiration of the second timer.

[0043] In addition, one embodiment of the present invention is a method for a terminal device communicating with a base station device, wherein an RRC message including a maximum value of a context identifier is received from the base station device, and when a third service data unit is received from an upper layer, a fourth context identifier associated with one of the stored contexts is assigned to the third context when a third context related to a header included in the third service data unit is not stored and the number of stored contexts reaches the maximum value of the context identifier.

[0044] In addition, one embodiment of the present invention is a method for a base station device to communicate with a terminal device, wherein an RRC message is sent to the terminal device, causing the terminal device to delete the context identifier and the context associated with the context identifier based on the context identifier of the released context included in the RRC message.

[0045] In addition, one embodiment of the present invention is a method for a base station device to communicate with a terminal device, wherein an RRC message is sent to the terminal device, so that the terminal device performs, based on the information for setting a context management timer included in the RRC message, when a first service data unit is received from an upper layer, generating a first context related to a header included in the first service data unit without storing a first context related to the header included in the first service data unit, and starting or restarting a first timer for the first context; starting or restarting the first timer when the first context related to the header included in the first service data unit is stored, and deleting the first context based on the expiration of the first timer.

[0046] In addition, one embodiment of the present invention is a method for a base station device communicating with a terminal device, wherein an RRC message is sent to the terminal device, so that the terminal device performs processing based on the fact that information for setting a context management timer is included in the RRC message. When a second protocol data unit is received from a lower layer, the terminal device generates a second context related to a header included in the second protocol data unit, starts or restarts a second timer for the second context, starts or restarts the second timer, and deletes the second context based on the expiration of the second timer.

[0047] In addition, one embodiment of the present invention is a method for a base station device to communicate with a terminal device, wherein an RRC message including a maximum value of a context identifier is sent to the terminal device, so that the terminal device performs processing of assigning a fourth context identifier associated with one of the stored contexts to the third context when receiving a third service data unit from an upper layer, when a third context related to a header included in the third service data unit is not stored and the number of stored contexts reaches the maximum value of the context identifier.

[0048] It should be noted that these inclusive or specific solutions can be implemented through systems, devices, methods, integrated circuits, computer programs or recording media, or through any combination of systems, devices, methods, integrated circuits, computer programs and recording media.

[0049] Beneficial effects

[0050] According to one aspect of the present invention, a terminal device can implement efficient mobility processing. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 This is a schematic diagram of a communication system according to each embodiment of the present invention.

[0052] Figure 2 This is a protocol stack diagram of UP and CP of a terminal apparatus and a base station apparatus in E-UTRA according to each embodiment of the present invention.

[0053] Figure 3 This is a protocol stack diagram of UP and CP of the terminal device and base station device in NR of each embodiment of the present invention.

[0054] Figure 4 This is a diagram showing an example of a flow of procedures for various settings in RRC208 and / or RRC308 according to each embodiment of the present invention.

[0055] Figure 5 It is a block diagram showing the configuration of a terminal device according to each embodiment of the present invention.

[0056] Figure 6 It is a block diagram showing the configuration of a base station apparatus according to each embodiment of the present invention.

[0057] Figure 7 This is an example of an ASN.1 description included in a message related to the re-establishment of an RRC connection in an NR according to an embodiment of the present invention.

[0058] Figure 8 This is an example of an ASN.1 description included in a message related to re-establishment of an RRC connection in E-UTRA according to an embodiment of the present invention.

[0059] Figure 9 This is an example of an ASN.1 description including an information element or field indicating application of Ethernet header compression in the RRC message of each aspect of the present embodiment.

[0060] Figure 10 This is an example of an ASN.1 description including an information element or field indicating an Ethernet PDU session in an RRC message according to an embodiment of the present invention.

[0061] Figure 11 This is an example of a processing method of the Ethernet header compression protocol according to an embodiment of the present invention.

[0062] Figure 12 This is a first example of a processing method of UE 122 according to an embodiment of the present invention.

[0063] Figure 13 This is an example of an ASN.1 description of information related to a released or deleted context included in an RRC message according to an embodiment of the present invention.

[0064] Figure 14 This is a second example of the processing method of UE 122 according to the embodiment of the present invention.

[0065] Figure 15 This is an example of an ASN.1 description including information elements or fields related to timers for managing contexts in the PDCP configuration information element according to the embodiment of the present invention.

[0066] Figure 16 This is a third example of the processing method of UE 122 according to the embodiment of the present invention. DETAILED DESCRIPTION

[0067] Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

[0068] LTE (and LTE-A Pro) and NR can be defined as different radio access technologies (Radio Access Technology: RAT). In addition, NR can be defined as a technology included in LTE. LTE can be defined as a technology included in NR. In addition, LTE that can be connected to NR through multi-radio dual connectivity can be distinguished from existing LTE. In addition, LTE with a core network of 5GC can be distinguished from existing LTE with a core network of EPC. This embodiment can be applied to NR, LTE, and other RATs. In the following description, terms associated with LTE and NR are used for description, but it can also be applied to other technologies using other terms. In addition, the term called E-UTRA in this embodiment can be replaced with a term called LTE, and the term called LTE can be replaced with a term called E-UTRA.

[0069] Figure 1 This is a schematic diagram of a communication system according to each embodiment of the present invention.

[0070] E-UTRA 100 is a radio access technology described in Non-Patent Document 3 and other publications, and includes cell groups (CGs) consisting of one or more frequency bands. An eNB (E-UTRAN Node B) 102 is a base station device for E-UTRA 100. An EPC (Evolved Packet Core) 104 is a core network described in Non-Patent Document 14 and other publications, designed for E-UTRA 100. An interface 112 is the interface between eNB 102 and EPC 104. It consists of a control plane (CP), which carries control signals, and a user plane (UP), which carries user data.

[0071] NR106 is a radio access technology described in Non-Patent Document 9 and other publications, and includes a cell group (CG) consisting of one or more frequency bands. gNB (g Node B) 108 is a base station device for NR106. 5GC110 is a core network described in Non-Patent Document 2 and other publications. While designed as a core network for NR106, it can also be used as a core network for E-UTRA100, which has the function of connecting to 5GC110. The following E-UTRA100 may include E-UTRA100, which has the function of connecting to 5GC110.

[0072] Interface 114 is the interface between eNB 102 and 5GC 110, interface 116 is the interface between gNB 108 and 5GC 110, interface 118 is the interface between gNB 108 and EPC 104, interface 120 is the interface between eNB 102 and gNB 108, and interface 124 is the interface between EPC 104 and 5GC 110. Interfaces 114, 116, 118, 120, and 124 may be interfaces that pass only through the CP, only through the UP, or through both the CP and the UP. Furthermore, interfaces 114, 116, 118, 120, and 124 may not exist depending on the communication system provided by the communication operator.

[0073] UE122 is a terminal device corresponding to any one or all of E-UTRA100 and NR106. As described in any one or all of non-patent document 3 and non-patent document 9, when UE122 is connected to the core network via any one or all of E-UTRA100 and NR106, a logical path called a radio bearer (RB) is established between UE122 and any one or all of E-UTRA100 and NR106. The radio bearer used for CP is called a signaling radio bearer (SRB), and the radio bearer used for UP is called a data radio bearer (DRB Data RadioBearer). Each RB is assigned an RB identifier (RB Identity or RB ID) and is identified as unique. The RB identifier for SRB is called an SRB identifier (SRB Identity or SRB ID), and the RB identifier for DRB is called a DRB identifier (DRB Identity or DRB ID).

[0074] As described in Non-Patent Document 3, when the core network to which UE 122 is connected is EPC 104, each DRB established between UE 122 and either or both of E-UTRA 100 and NR 106 is further uniquely associated with each EPS (Evolved Packet System) bearer passing through EPC 104. Each EPS bearer is uniquely identified by an assigned EPS bearer identifier (Identity or ID). Furthermore, the same QoS is guaranteed for data passing through the same EPS bearer.

[0075] As described in non-patent document 9, when the connection destination core network of UE122 is 5GC110, one or more DRBs established between UE122 and any one or all of E-UTRA100 and NR106 are further associated with one of the PDU (Packet Data Unit) sessions to be established within 5GC110. There are one or more QoS processes in each PDU session. Each DRB may be mapped to one or more QoS processes within the associated PDU session, or may not be mapped to any QoS process. Each PDU session is identified by a PDU session identifier (Identity or ID). In addition, each QoS process is identified by a QoS process identifier. In addition, the same QoS is guaranteed for data passing through the same QoS process.

[0076] There is no PDU session or QoS process in EPC 104, and no EPS bearer in 5GC 110. In other words, when UE 122 is connected to EPC 104, UE 122 has information about the EPS bearer, and when UE 122 is connected to 5GC 110, UE 122 has information about the PDU session or QoS process.

[0077] In the following description, eNB102 and / or gNB108 are also referred to only as base station devices, and UE122 is also referred to only as terminal devices.

[0078] Figure 2 This is a diagram of the protocol stack of the UP and CP of the terminal device and the base station device in the E-UTRA radio access layer (Radio Access Layer) of each embodiment of the present invention.

[0079] Figure 2 (A) is a diagram of a protocol stack of UP used when the UE 122 communicates with the eNB 102 in E-UTRA 100.

[0080] The PHY (Physical layer) 200 is the radio physical layer, providing transport services to upper layers using physical channels. PHY 200 connects to the upper-level MAC (Medium Access Control layer) 202, described later, via a transport channel. Data moves between MAC 202 and PHY 200 via the transport channel. Data is transmitted and received between the PHYs of UE 122 and eNB 102 via radio physical channels.

[0081] MAC202 is a medium access control layer that maps multiple logical channels to multiple transport channels. MAC202 is connected to the upper-level RLC (Radio Link Control) layer 204, described later, via logical channels. Logical channels are broadly classified according to the type of information being transmitted, into control channels for transmitting control information and traffic channels for transmitting user information. MAC202 has the functions of controlling PHY200 for intermittent transmission and reception (DRX / DTX), executing random access procedures, notifying transmission power information, and performing HARQ control (Non-Patent Document 7).

[0082] The RLC 204 is the Radio Link Control layer that segments data received from the higher-level PDCP (Packet Data Convergence Protocol) Layer 206, described later, and adjusts the data size to enable appropriate data transmission by the lower layer. Furthermore, the RLC 204 has the function of guaranteeing the QoS (Quality of Service) requested for each data item. Specifically, the RLC 204 has functions such as data retransmission control (Non-Patent Document 6).

[0083] PDCP 206 is a Packet Data Convergence Protocol layer used to efficiently transmit IP packets, which are user data, within wireless networks. PDCP 206 can include header compression to reduce unnecessary control information. Furthermore, PDCP 206 can also include data encryption (Non-Patent Document 5).

[0084] It should be noted that data processed by MAC 202, RLC 204, and PDCP 206 are referred to as MAC PDU (Protocol Data Unit), RLC PDU, and PDCP PDU, respectively. Furthermore, data transferred from upper layers to MAC 202, RLC 204, and PDCP 206, or transferred to upper layers, are referred to as MAC SDU (Service Data Unit), RLC SDU, and PDCP SDU, respectively.

[0085] To distinguish between data and control, PDCP PDUs may also be referred to as PDCP DATA PDUs (PDCP Data PDU: PDCP Data PDU) and PDCP CONTROL PDUs (PDCP Control PDU: PDCP Control PDU). To distinguish between data and control, RLC PDUs may also be referred to as RLC DATA PDUs (RLC Data PDU: RLC Data PDU) and RLC CONTROL PDUs (RLC Control PDU: RLC Control PDU).

[0086] Figure 2 (B) is a protocol stack diagram of CP used when the UE 122 communicates with the eNB 102 and the MME (Mobility Management Entity) which is a logical node providing functions such as authentication and mobility management in the E-UTRA 100.

[0087] In the CP protocol stack, in addition to PHY200, MAC202, RLC204, and PDCP206, there are also RRC (Radio Resource Control layer) 208 and NAS (Non Access Stratum) 210. RRC208 is a radio link control layer that not only performs processes such as establishing, reestablishing, suspending, and resuming RRC connections, resetting RRC connections, such as establishing, changing, and releasing radio bearers (RBs) and cell groups, and controlling logical channels, transport channels, and physical channels, but also performs settings for handovers and measurements. RBs can be divided into signaling radio bearers (SRBs) and data radio bearers (DRBs). SRBs can be used as paths for sending RRC messages as control information. DRBs can be used as paths for sending user data. Each RB can be configured between the RRC 208 of the eNB 102 and the UE 122. Furthermore, the portion of the RB consisting of the RLC 204 and MAC 202 can also be referred to as an RLC bearer (Non-Patent Document 4). Furthermore, with respect to the NAS layer that carries signals between the MME and the UE 122, some or all of the layers of the PHY 200, MAC 202, RLC 204, PDCP 206, and RRC 208 that carry signals and data between the UE 122 and the eNB 102 can be referred to as the AS (Access Stratum) layer.

[0088] The functions of MAC 202 , RLC 204 , PDCP 206 , and RRC 208 described above are merely examples, and some or all of the functions may not be implemented. Furthermore, some or all of the functions of each layer may be included in other layers.

[0089] It should be noted that the IP layer and the TCP (Transmission Control Protocol) layer (TCP layer), UDP (User Datagram Protocol) layer (UDP layer), and application layer, which are layers above the IP layer, are upper layers of the PDCP layer (not shown). In addition, the RRC layer and NAS (non-Access Strarum) layer are also upper layers of the PDCP layer (not shown). In other words, the PDCP layer is the lower layer of the RRC layer, NAS layer, IP layer, and the TCP (Transmission Control Protocol) layer, UDP (User Datagram Protocol) layer, and application layer, which are layers above the IP layer.

[0090] Figure 3 This is a protocol stack diagram of the UP and CP of the terminal device and base station device in the NR wireless access layer of each embodiment of the present invention.

[0091] Figure 3 (A) is a protocol stack diagram of UP used when UE122 communicates with gNB108 in NR106.

[0092] The PHY (Physical layer) 300 is the NR radio physical layer and provides transport services to upper layers using physical channels. The PHY 300 connects to the upper-level MAC (Medium Access Control layer) 302, described later, via a transport channel. Data can be transferred between the MAC 302 and the PHY 300 via the transport channel. Data can be sent and received between the UE 122 and the gNB 108 PHY via the wireless physical channel.

[0093] Here, the physical channel is described.

[0094] The following physical channels can be used for wireless communication between a terminal device and a base station device.

[0095] PBCH (Physical Broadcast Channel)

[0096] PDCCH (Physical Downlink Control Channel)

[0097] PDSCH (Physical Downlink Shared Channel)

[0098] PUCCH (Physical Uplink Control Channel)

[0099] PUSCH (Physical Uplink Shared Channel)

[0100] PRACH (Physical Random Access Channel)

[0101] PBCH is used to broadcast system information required by terminal devices.

[0102] In addition, in NR, PBCH can be used to broadcast the time index (SSB-Index) within the period of the block of synchronization signals (also called SS / PBCH block).

[0103] PDCCH is used to send (or transport) downlink control information (Downlink Control Information: DCI) in downlink wireless communication (wireless communication from the base station device 3 to the terminal device). Here, one or more DCIs (also referred to as DCI formats) are defined for the transmission of downlink control information. That is, the field for downlink control information is defined as DCI and mapped to information bits. PDCCH is sent in PDCCH candidates. The terminal device monitors a set of PDCCH candidates in the serving cell. Monitoring means attempting to decode the PDCCH according to a certain DCI format. A certain DCI format can be used for scheduling PUSCH in the serving cell. PUSCH can be used for sending user data, sending RRC messages, etc.

[0104] The PUCCH can be used to transmit uplink control information (UCI) in uplink wireless communication (wireless communication from a terminal device to a base station device). Here, the uplink control information may include channel state information (CSI: Channel State Information) for indicating the state of a downlink channel. In addition, the uplink control information may include a scheduling request (SR: Scheduling Request) for requesting UL-SCH resources. In addition, the uplink control information may include a HARQ-ACK (Hybrid Automatic Repeat request ACKnowledgement: Hybrid Automatic Repeat request acknowledgment).

[0105] The PDSCH can be used to transmit downlink data (DL-SCH: Downlink Shared CHannel) from the MAC layer. In addition, in the case of downlink, it is also used to transmit system information (SI: System Information), random access response (Random Access Response: RAR), etc.

[0106] PUSCH can be used to send HARQ-ACK and / or CSI together with uplink data (UL-SCH: Uplink Shared CHannel) or uplink data from the MAC layer. In addition, it can also be used to send only CSI or only HARQ-ACK and CSI. That is, it can also be used to send only UCI. In addition, PDSCH or PUSCH can be used to send RRC signaling (also called RRC message) and MAC control elements. Here, in PDSCH, the RRC signaling sent from the base station device can be signaling shared by multiple terminal devices in the cell. In addition, the RRC signaling sent from the base station device can also be signaling dedicated to a certain terminal device (also called dedicated signaling). That is, dedicated signaling can be used to send terminal device-specific (UE-specific) information to a certain terminal device. In addition, PUSCH can be used to send UE capabilities (UE Capability) in the uplink.

[0107] PRACH can be used to transmit random access preambles. PRACH can be used to indicate the initial connection establishment procedure, handover procedure, connection re-establishment procedure, synchronization (timing adjustment) for uplink transmission, and PUSCH (UL-SCH) resource requests.

[0108] MAC302 is a medium access control layer that maps multiple logical channels to multiple transmission channels. MAC302 can be connected to the upper-level RLC (Radio Link Control) layer 304 described later through logical channels. Logical channels can be roughly classified according to the type of information transmitted, into control channels for transmitting control information and service channels for transmitting user information. MAC302 can have the function of controlling PHY300 for intermittent transmission and reception (DRX / DTX), the function of executing the random access process, the function of notifying transmission power information, and the function of performing HARQ control, etc. (Non-patent document 13).

[0109] The RLC 304 is the Radio Link Control layer that segments data received from the higher-level PDCP (Packet Data Convergence Protocol) Layer 306, described later, and adjusts the data size to enable appropriate data transmission by the lower layers. Furthermore, the RLC 304 may also have the function of guaranteeing the QoS (Quality of Service) requested for each data item. Specifically, the RLC 304 may have functions such as data retransmission control (Non-Patent Document 12).

[0110] PDCP306 is the Packet Data Convergence Protocol layer that efficiently transmits user data within wireless ranges. PDCP306 can have a header compression function that compresses unnecessary control information. In addition, PDCP306 can also have data encryption and data integrity protection functions (Non-Patent Document 11). It should be noted that the above-mentioned user data can be either IP packets or Ethernet frames described in Non-Patent Document 19, etc., but is not limited to these.

[0111] SDAP (Service Data Adaptation Protocol) 310 is a service data adaptation protocol layer (Service Data Adaptation Protocol layer) with the following functions: establishing the correspondence (mapping) between the downlink QoS flow sent from the 5GC110 via the base station device to the terminal device and the DRB, and mapping the uplink QoS flow sent from the terminal device via the base station device to the 5GC110 and the DRB, and storing mapping rule information (non-patent document 16).

[0112] It should be noted that the data processed by MAC 302, RLC 304, PDCP 306, and SDAP 310 are respectively referred to as MAC PDU (Protocol Data Unit), RLC PDU, PDCP PDU, and SDAP PDU. Furthermore, data forwarded from upper layers to MAC 302, RLC 304, PDCP 306, and SDAP 310, or forwarded to upper layers, may also be referred to as MAC SDU (Service Data Unit), RLC SDU, PDCP SDU, and SDAP SDU, respectively.

[0113] To distinguish between data and control use, the SDAP PDU may also be referred to as the SDAP DATA PDU (SDAP Data PDU) and the SDAP CONTROL PDU (SDAP Control PDU), respectively. To distinguish between data and control use, the PDCP PDU may also be referred to as the PDCP DATA PDU (PDCP Data PDU) and the PDCP CONTROL PDU (PDCP Control PDU), respectively. To distinguish between data and control use, the RLC PDU may also be referred to as the RLC DATA PDU (RLC Data PDU) and the RLC CONTROL PDU (RLC Control PDU), respectively.

[0114] Figure 3 (B) is a protocol stack diagram of the CP used when UE122 communicates with gNB108 and AMF (Access and Mobility Management function), which is a logical node providing functions such as authentication and mobility management in NR106.

[0115] In the CP protocol stack, in addition to PHY 300, MAC 302, RLC 304, and PDCP 306, there are also RRC (Radio Resource Control) layer 308 and NAS (Non Access Stratum) 312. RRC 308 is the Radio Link Control layer that performs processes such as establishing, reestablishing, suspending, and resuming RRC connections, reconfiguring RRC connections, such as establishing, changing, and releasing radio bearers (RBs) and cell groups, and controlling logical, transport, and physical channels. It also performs settings for handovers and measurements. RBs can be divided into signaling radio bearers (SRBs) and data radio bearers (DRBs). SRBs can be used as paths for transmitting RRC messages, which serve as control information. DRBs can be used as paths for transmitting user data. Each RB can be configured between the RRC 308 of the gNB 108 and the UE 122. Furthermore, the portion of the RB consisting of the RLC 304 and MAC 302 may also be referred to as an RLC bearer (Non-Patent Document 10). Furthermore, with respect to the NAS layer that carries signals between the AMF and the UE 122, some or all of the layers of the PHY 300, MAC 302, RLC 304, PDCP 306, RRC 308, and SDAP 310 that carry signals and data between the UE 122 and the gNB 108 may be referred to as the AS (Access Stratum) layer.

[0116] In addition, SRBs may be defined as follows: SRB0 to SRB3. SRB0 may be an SRB for RRC messages using the CCCH (Common Control Channel) of a logical channel. SRB1 may be an SRB used for (possibly including piggybacked NAS messages) RRC messages and NAS messages before the establishment of SRB2, or it may use the DCCH (Dedicated Control CHannel) of the logical channel in its entirety. SRB2 may be an SRB used for NAS messages, or it may use the DCCH of the logical channel in its entirety. In addition, SRB2 may have a lower priority than SRB1. SRB3 may be an SRB used for specific RRC messages when UE122 is configured with EN-DC, NGEN-DC, NR-DC, etc., or it may use the DCCH of the logical channel in its entirety. In addition, other SRBs may be prepared for other purposes.

[0117] The functions of MAC 302 , RLC 304 , PDCP 306 , SDAP 310 , and RRC 308 described above are merely examples, and some or all of the functions may not be implemented. Furthermore, some or all of the functions of each layer may be included in other layers.

[0118] It should be noted that, as described in non-patent document 2, the upper layer of the AS layer (not shown) can also be called the PDU layer (PDU layer). The PDU layer can also include the IP layer, the TCP (Transmission Control Protocol) layer above the IP layer, the UDP (User Datagram Protocol) layer, the Ethernet layer, and any or all of the other layers. The application layer can be an upper layer of the PDU layer, and can also be included in the PDU layer. It should be noted that the PDU layer can also be an upper layer of the user plane relative to the AS layer. In addition, the RRC layer and the NAS (non Access Strarum) layer can also be the upper layers of any or all of the SDAP layer and the PDCP layer (not shown). In other words, any or all of the SDAP layer and the PDCP layer are lower layers of the RRC layer, the NAS layer, the IP layer, and any or all of the TCP (Transmission Control Protocol) layer above the IP layer, the UDP (User Datagram Protocol) layer, the Ethernet layer, and the application layer.

[0119] It should be noted that the above-mentioned Ethernet layer may be a layer having a function of processing Ethernet frames as described in Non-Patent Document 19, etc., but is not limited thereto.

[0120] It should be noted that in each embodiment of the present invention, any one or all of the SIP (Session Initiation Protocol), SDP (Session Description Protocol), etc. used in IMS, as well as RTP (Real-time Transport Protocol), RTCP (Real-time Transport Control Protocol), HTTP (HyperText Transfer Protocol), etc. used for media communication or media communication control, and codecs for various media may belong to the application layer.

[0121] It should be noted that any one or all of the physical layer, MAC layer, RLC layer, PDCP layer and SDAP layer of the terminal device can also be established, set and controlled by the RRC layer of the terminal device. In addition, the RRC layer of the terminal device can also establish and / or set the physical layer, MAC layer, RLC layer, PDCP layer and SDAP layer based on the RRC message sent from the RRC layer of the base station device. In addition, the MAC layer (MAC layer), RLC layer (RLC layer), PDCP layer (PDCP layer), and SDAP layer (SDAP layer) can also be referred to as the MAC sublayer (MAC sublayer), RLC sublayer (RLC sublayer), PDCP sublayer (PDCP sublayer), and SDAP sublayer (SDAP sublayer), respectively.

[0122] It should be noted that the layers or functions of the layers belonging to any or all of the AS layers set in the terminal device and the base station device may also be referred to as entities. That is, any or all of the physical layers (PHY layers), MAC layers, RLC layers, PDCP layers, SDAP layers and RRC layers or functions of the layers established, set and controlled in any or all of the terminal device and the base station device may also be referred to as physical entities (PHY entities), MAC entities, RLC entities, PDCP entities, SDAP entities and RRC entities. In addition, each layer may also include one or more entities of each layer. In addition, any or all of the PDCP entities and RLC entities may also be established, set and controlled for each radio bearer. In addition, any or all of the MAC entities may also be established, set and controlled for each cell group. In addition, any or all of the SDAP entities may also be established, set and controlled for each PDU session.

[0123] It should be noted that the COUNT value may also be used when performing encryption or integrity protection processing in the PDCP layer or PDCP entity. The COUNT value may include the HFN (Hyper Frame Number) and the sequence number (SN) attached to the header of the PDCP PDU. The sequence number may be incremented by 1 each time the PDCP layer or PDCP entity on the transmitting side generates a PDCP DATA PDU. The HFN may be incremented by 1 each time the sequence number reaches its maximum value.

[0124] It should be noted that in the various embodiments of the present invention, to distinguish between E-UTRA protocols and NR protocols, MAC 202, RLC 204, PDCP 206, and RRC 208 are referred to as E-UTRA MAC or LTE MAC, E-UTRA RLC or LTE RLC, E-UTRA PDCP or LTE PDCP, and E-UTRA RRC or LTE RRC, respectively. Furthermore, MAC 302, RLC 304, PDCP 306, and RRC 308 are referred to as NR MAC, NR RLC, NR RLC, and NR RRC, respectively. Alternatively, spaces may be used to describe E-UTRA PDCP, LTE PDCP, NR PDCP, and so on.

[0125] In addition, if Figure 1 As shown, eNB 102, gNB 108, EPC 104, and 5GC 110 can be connected via interfaces 112, 116, 118, 120, and 114. Therefore, in order to correspond to various communication systems, Figure 2 RRC208 can be replaced by Figure 3RRC308. In addition, Figure 2 The PDCP206 can also be replaced by Figure 3 PDCP 306. In addition, Figure 3 The RRC 308 may include Figure 2 The function of RRC208. In addition, Figure 3 The PDCP 306 can be Figure 2 PDCP 206. In addition, in E-UTRA 100, even when UE 122 communicates with eNB 102, NR PDCP can be used as PDCP.

[0126] Next, the state transitions of UE 122 in LTE and NR are described. A UE 122 connected to the EPC may be in the RRC_CONNECTED state when an RRC connection has been established. Furthermore, a UE 122 may be in the RRC_INACTIVE state when the RRC connection is terminated (if the UE 122 is connected to a 5GC). Otherwise, the UE 122 may be in the RRC_IDLE state.

[0127] It should be noted that UE 122 connected to the EPC does not have the RRC_INACTIVE state, but can initiate the termination of the RRC connection through the E-UTRAN. In this case, when the RRC connection is terminated, UE 122 retains the UE's AS context and the identifier for resumption (resumeIdentity) and transitions to the RRC_IDLE state. If UE 122 retains the UE's AS context and the E-UTRAN permits the resumption of the RRC connection, and UE 122 needs to transition from the RRC_IDLE state to the RRC_CONNECTED state, the upper layer (e.g., the NAS layer) can initiate the resumption of the terminated RRC connection.

[0128] That is, the definition of suspension may differ between UE 122 connected to the EPC and UE 122 connected to the 5GC. In addition, all or part of the process of resuming from suspension may differ between the case where UE 122 is connected to the EPC (suspended in the RRC_IDLE state) and the case where UE 122 is connected to the 5GC (suspended in the RRC_INACTIVE state).

[0129] It should be noted that the RRC_CONNECTED state, RRC_INACTIVE state, and RRC_IDLE state may be referred to as a connected mode, an inactive mode, and an idle mode, respectively.

[0130] The AS context of the UE maintained by UE122 may include all or part of the current RRC settings, the current security context, the PDCP state including the ROHC (RObust Header Compression) state, the C-RNTI (Cell Radio Network Temporary Identifier) ​​used in the PCell of the connection source (Source), the cell identifier (cellIdentity), and the physical cell identifier of the PCell of the connection source. It should be noted that the AS context of the UE maintained by any one or all of eNB102 and gNB108 may include the same information as the AS context of the UE maintained by UE122, and may also include information different from the information included in the AS context of the UE maintained by UE122.

[0131] The security context may refer to all or part of the information including the encryption key at the AS level, NH (Next Hop parameter), NCC (Next Hop Chaining Counter parameter) for deriving the access key of the next hop, the identifier of the selected AS-level encryption algorithm, and the counter used for replay protection.

[0132] Figure 4 This is a diagram showing an example of a flow of procedures for various settings in RRC208 and / or RRC308 according to each embodiment of the present invention. Figure 4 This is an example of a process in which an RRC message is sent from a base station device (eNB102 and / or gNB108) to a terminal device (UE122).

[0133] exist Figure 4In the process, the base station device generates an RRC message (step S400). The generation of the RRC message in the base station device can be performed when the base station device distributes broadcast information (SI: System Information) and paging information, or when it is determined that the base station device needs to process a specific terminal device, such as security-related settings, re-setting of the RRC connection (processing of wireless line bearers (establishment, change, release, etc.), processing of cell groups (establishment, addition, change, release, etc.), measurement settings, switching settings, etc.), release of the RRC connection state, etc. In addition, the RRC message can be used for switching commands to different RATs. The RRC message includes information (parameters) for various information notifications and settings. In the specifications related to RRC, such as non-patent document 4 or non-patent document 10, these parameters can also be referred to as fields and / or information elements, and are described using the description method of ASN.1 (Abstract Syntax Notation One).

[0134] exist Figure 4 Then, the base station device transmits the generated RRC message to the terminal device (step S402). Then, the terminal device performs processing such as configuration according to the received RRC message if necessary (step S404).

[0135] It should be noted that the generation of RRC messages is not limited to the above examples, and can also be generated for other purposes as described in non-patent document 4, non-patent document 10, etc.

[0136] For example, the RRC message can be used for settings related to dual connectivity (Dual Connectivity: DC) and multi-radio dual connectivity (Multi-Radio Dual Connectivity: MR-DC) described in Non-Patent Document 8.

[0137] Dual Connectivity (DC) can be a technology that uses the radio resources of both the Master Cell Group (MCG) and the Secondary Cell Group (SCG) to perform data communication. The master node and the secondary node can be the same node (the same base station device). MR-DC, as described in non-patent document 8, can be a technology that groups cells of both E-UTRA and NR RATs (Radio Access Technology) for each RAT and allocates them to UEs, using the radio resources of both the MCG and the SCG to perform data communication. In MR-DC, the master node can be a base station that has the main RRC functions of MR-DC, such as the addition of secondary nodes, the establishment, change, and release of RBs, and the addition, change, release, and switching of MCGs. The secondary node can be a base station that has some RRC functions, such as the change and release of SCGs.

[0138] In the MR-DC described in non-patent document 8, the RRC of the RAT on the master node side can be used to set up both the MCG and the SCG. For example, in EN-DC (E-UTRA-NR Dual Connectivity: E-UTRA-NR dual connectivity) of MR-DC in the case where the core network is EPC104 and the master node is eNB102 (also called extended eNB102), and in NGEN-DC (NG-RAN E-UTRA-NR Dual Connectivity: NG-RAN E-UTRA-NR dual connectivity) of MR-DC in the case where the core network is 5GC110 and the master node is eNB102, the RRC message of E-UTRA described in non-patent document 4 can be sent and received between eNB102 and UE122. In this case, the RRC message can include not only the setting information of LTE (E-UTRA), but also the setting information of NR described in non-patent document 10. In addition, the RRC message sent from eNB 102 to UE 122 can also be sent from eNB 102 to UE 122 via gNB 108. In addition, the structure of this RRC message can also be used for non-MR-DC, that is, E-UTRA / 5GC (Option 5 described in Non-Patent Document 17) in which eNB 102 (extended eNB) uses 5GC as the core network.

[0139] Furthermore, conversely, in MR-DC described in non-patent document 8, in NE-DC (NR-E-UTRA Dual Connectivity), which is MR-DC in which the core network is 5GC 110 and the master node is gNB 108, NR RRC messages described in non-patent document 10 can be sent and received between gNB 108 and UE 122. In this case, the RRC messages can include not only NR configuration information but also LTE (E-UTRA) configuration information described in non-patent document 4. Furthermore, RRC messages sent from gNB 108 to UE 122 can also be sent from gNB 108 to UE 122 via eNB 102.

[0140] It should be noted that, not limited to the case of using MR-DC, the RRC message for E-UTRA sent from eNB102 to UE122 can include the RRC message for NR, and the RRC message for NR sent from gNB108 to UE122 can include the RRC message for E-UTRA.

[0141] In addition, the network configuration in which the master node is eNB102 and EPC104 is used as the core network may be referred to as E-UTRA / EPC. In addition, the network configuration in which the master node is eNB102 and 5GC110 is used as the core network may be referred to as E-UTRA / 5GC. In addition, the network configuration in which the master node is gNB108 and 5GC110 is used as the core network may be referred to as NR or NR / 5GC. In addition, this name may not be limited to the case where DC is set. When DC is not set, the above-mentioned master node may refer to a base station device that communicates with the terminal device.

[0142] Figure 5 The illustrated UE 122 includes a receiving unit 500 for receiving RRC messages and the like from a base station apparatus; a processing unit 502 for performing processing based on any or all of the configuration information, including various information elements (IEs), various fields, and various conditions, included in the received message; and a transmitting unit 504 for transmitting the RRC messages and the like to the base station apparatus. The base station apparatus described above may sometimes refer to the eNB 102 or sometimes to the gNB 108. Furthermore, the processing unit 502 may include some or all of the functions of various layers (e.g., the physical layer, MAC layer, RLC layer, PDCP layer, SDAP layer, RRC layer, and NAS layer). Specifically, the processing unit 502 may include some or all of the physical layer processing unit, the MAC layer processing unit, the RLC layer processing unit, the PDCP layer processing unit, the RRC layer processing unit, and the NAS layer processing unit.

[0143] Figure 6It is a block diagram showing the configuration of a base station device according to each embodiment of the present invention. Figure 6 Only the main components closely related to one embodiment of the present invention are shown. The above-mentioned base station device sometimes refers to eNB102 and sometimes refers to gNB108.

[0144] Figure 6 The illustrated base station apparatus includes: a transmitting unit 600 for transmitting RRC messages and other information to UE 122; a processing unit 602 for generating an RRC message including configuration information for any or all of various information elements (IEs), various fields, and various conditions, and transmitting the message to UE 122 for processing by processing unit 502 of UE 122; and a receiving unit 604 for receiving the RRC message and other information from UE 122. Furthermore, processing unit 602 may include some or all of the functions of various layers (e.g., the physical layer, MAC layer, RLC layer, PDCP layer, RRC layer, and NAS layer). Specifically, processing unit 602 may include some or all of the physical layer processing unit, MAC layer processing unit, RLC layer processing unit, PDCP layer processing unit, SDAP layer processing unit, RRC layer processing unit, and NAS layer processing unit.

[0145] Figure 7 It means in Figure 4 An example of an ASN.1 description of any or all of the fields and information elements related to radio bearer setup included in a message related to re-establishment of an RRC connection in NR. Figure 8 It means in Figure 4 An example of an ASN.1 description of any or all of the fields and information elements related to radio bearer setup included in a message related to re-establishment of an RRC connection in E-UTRA. Figure 7 、 Figure 8In the ASN.1 examples of the embodiments of the present invention, <omitted> and <information omitted> indicate the omission of other information, not the omission of a portion of the ASN.1 expression. It should be noted that in places where there is no such expression, information elements may be omitted. It should be noted that the ASN.1 examples of the embodiments of the present invention do not strictly follow the ASN.1 expression method, but rather are examples of parameters of messages related to RRC connection reconfiguration in the embodiments of the present invention. Other names and expressions may also be used. Furthermore, the ASN.1 examples of the embodiments of the present invention only illustrate examples of essential information closely related to one aspect of the present invention. It should be noted that in the embodiments of the present invention, parameters described in ASN.1 are distinguished from fields, information elements, etc., and are all referred to as information elements. Furthermore, in the embodiments of the present invention, parameters such as fields and information elements described in ASN.1 included in RRC messages may also be referred to as information. It should be noted that the message related to RRC connection reconfiguration can be either an RRC connection reconfiguration message in NR or an RRC connection reconfiguration message in E-UTRA.

[0146] exist Figure 7 The information element represented by RadioBearerConfig in the message is an information element related to the setting of radio bearers such as SRB and DRB, including the PDCP setting information element and SDAP setting information element described later. The information element represented by SRB-ToAddMod included in the information element represented by RadioBearerConfig can be information indicating the setting of SRB (signaling radio bearer), and is sometimes also referred to as an SRB setting information element or a signaling radio bearer setting information element. In addition, the information element represented by SRB-ToAddModList can be a list of information indicating SRB setting. The information element represented by DRB-ToAddMod included in the information element represented by RadioBearerConfig can be information indicating the setting of DRB (data radio bearer), and is sometimes also referred to as a DRB setting information element or a data radio bearer setting information element. The information element represented by DRB-ToAddModList can be a list of information indicating DRB setting. It should be noted that sometimes any one or all of SRB setting and DRB setting are also referred to as radio bearer setting.

[0147] The information element represented by SRB-Identity in the SRB configuration information element is the SRB identifier (SRB Identity) of the SRB to be added or changed, or it can be an identifier that uniquely identifies the SRB in each terminal device. It is sometimes also referred to as the SRB identifier information element, the radio bearer identifier information element, or the signaling radio bearer identifier information element.

[0148] The information element represented by DRB-Identity in the DRB setting information element is the DRB identifier (DRB Identity) information of the DRB to be added or changed, and can also be an identifier that identifies the DRB as a unique one in each terminal device. Sometimes it is also called the DRB identifier information element or the radio bearer identifier information element or the data radio bearer identifier information element. Figure 7 In the example of , the value of the DRB identifier is set to an integer value from 1 to 32, but it can also take other values. In the case of DC, the DRB identifier is unique within the scope of UE122.

[0149] The information element represented by cnAssociation in the DRB setting information element can be an information element indicating whether EPC104 or 5GC110 is used in the core network, and is sometimes also said to be a core network association information element. That is, when UE122 is connected to EPC, the DRB can be associated with the EPS bearer identifier information element (eps-BearerIdentity) in cnAssociation or the EPS bearer identifier (EPS beareridentity) as the value of the EPS bearer identifier information element. When UE122 is connected to 5GC110, the DRB can be associated with the SDAP entity set according to the SDAP setting information element (sdap-Config) described later, or the PDU session information element described later included in the SDAP setting information element, or the PDU session identifier as the value of the PDU session information element, or the PDU session indicated by the PDU session information element. That is, in the information represented by cnAssociation, when EN-DC is used and EPC104 is used in the core network, the EPS bearer identifier information element (eps-BearerIdentity) may be included; when 5GC110 is used in the core network, that is, when EN-DC is not used, the information element (sdap-Config) representing the SDAP setting may be included.

[0150] In the case where the core network is 5GC110, the information element represented by sdap-Config can be information related to the setting or resetting of the SDAP entity to determine the mapping method between QoS flows and DRBs, and is sometimes also called an SDAP setting information element.

[0151] The field or information element represented by pdu-session or PDU-SessionID included in the SDAP setting information element may be the PDU session identifier of the PDU session described in non-patent document 2 to which the QoS flow mapped to the radio bearer corresponding to the value of the radio bearer identifier information element, included in the DRB setting information element including this SDAP setting information element, and is sometimes also referred to as the PDU session identifier information element. The value of the PDU session identifier information element may be a non-negative integer. In addition, in each terminal device, multiple DRB identifiers may correspond to one PDU session identifier.

[0152] The information element represented by "mappedQoS-FlowsToAdd" included in the SDAP setting information element may include a list of QoS flow identifiers (QFI) information elements (described later) indicating the QoS flows mapped or added to the radio bearer corresponding to the value of the radio bearer identifier information element, included in the DRB setting information element of this SDAP setting information element. This QoS flow may be a QoS flow of the PDU session indicated by the PDU session information element included in this SDAP setting information element.

[0153] Furthermore, the information element represented by mappedQoS-FlowsToRelease included in the SDAP setting information element may include a list of QoS flow identifiers (QFI: QoS Flow Identity) information elements, described later, indicating the QoS flows to be released from the QoS flows mapped to the radio bearer corresponding to the value of the radio bearer identifier information element, included in the DRB setting information element of this SDAP setting information element. This QoS flow may be a QoS flow of the PDU session indicated by the PDU session information element included in this SDAP setting information element.

[0154] The information element represented by QFI may be a QoS flow identifier, described in Non-Patent Document 2, that uniquely identifies a QoS flow, sometimes also referred to as a QoS flow identifier information element. The value of the QoS flow identifier information element may be a non-negative integer. Furthermore, the value of the QoS flow identifier information element may be unique for a PDU session.

[0155] In addition, the SDAP setting information element may include, among other things, an uplink header information element indicating whether an uplink SDAP header exists in the uplink data sent via the set DRB, a downlink header information element indicating whether an downlink SDAP header exists in the downlink data received via the set DRB, a default bearer information element indicating whether the set DRB is a default radio bearer (default DRB), and the like.

[0156] Furthermore, the information element represented by "pdcp-Config" or "PDCP-Config" in the SRB configuration information element and the DRB configuration information element may be an information element related to the configuration of the NR PDCP entity, used for establishing or changing the PDCP 306 for SRB and / or DRB, and may also be referred to as a "PDCP configuration information element." Information elements related to the configuration of the NR PDCP entity may include an information element indicating the size of the uplink sequence number, an information element indicating the size of the downlink sequence number, an information element indicating the profile of header compression (RoHC), a reordering timer information element, and the like.

[0157] The information element represented by DRB-ToReleaseList included in the information element represented by RadioBearerConfig may include information indicating one or more DRB identifiers to be released.

[0158] exist Figure 8The information element represented by RadioResourceConfigDedicated in the message element may also be an information element used for setting, changing, releasing, etc. a radio bearer. The information element represented by SRB-ToAddMod included in the information element represented by RadioResourceConfigDedicated may be information indicating SRB (signaling radio bearer) setting, sometimes also in other words, an SRB setting information element or a signaling radio bearer setting information element. The information element represented by SRB-ToAddModList may be a list of information indicating SRB setting. The information element represented by DRB-ToAddMod included in the information element represented by RadioResourceConfigDedicated may be information indicating DRB (data radio bearer) setting, sometimes also in other words, a DRB setting information element or a data radio bearer setting information element. The information element represented by DRB-ToAddModList may be a list of information indicating DRB setting. It should be noted that, sometimes, any one or all of SRB setting and DRB setting are also in other words referred to as radio bearer setting.

[0159] The information element represented by SRB-Identity in the SRB configuration information element is the SRB identifier (SRB Identity) of the SRB to be added or changed, or it can be an identifier that uniquely identifies the SRB in each terminal device. It is sometimes also referred to as the SRB identifier information element, the radio bearer identifier information element, or the signaling radio bearer identifier information element. Figure 8 The information element represented by SRB-Identity can also be Figure 7 The information element represented by SRB-Identity has the same function as the information element represented by SRB-Identity.

[0160] The information element represented by DRB-Identity in the DRB setting is the DRB identifier (DRB Identity) information of the DRB to be added or changed, or it can be an identifier that identifies the DRB as a unique one in each terminal device. Sometimes it is also called the DRB identifier information element or the radio bearer identifier information element or the data radio bearer identifier information element. Figure 8 In the example shown in FIG, the value of the DRB identifier is set to an integer value from 1 to 32, but it can also take other values. Figure 8 The information element represented by DRB-Identity can also be Figure 7 The information element represented by DRB-Identity has the same function as the information element represented by DRB-Identity.

[0161] The information element represented by eps-BearerIdentity in the DRB setting information element may be an EPS bearer identifier that uniquely identifies the EPS bearer in each terminal device. The information element represented by eps-BearerIdentity is sometimes also referred to as an EPS bearer identifier information element. Figure 8 In the example shown in FIG, the value of the EPS bearer identifier is set to an integer value from 1 to 15, but other values ​​are also possible. Figure 8 The information element represented by eps-BearerIdentity can also be Figure 7 The information element represented by eps-BearerIdentity has the same function as the information element. In addition, in each terminal device, the EPS bearer identifier and the DRB identifier can also correspond one to one.

[0162] Furthermore, the information element represented by "pdcp-Config" or "PDCP-Config" in the SRB configuration information element and the DRB configuration information element may be an information element related to the configuration of the E-UTRA PDCP entity, used to establish or modify the PDCP 206 for SRB and / or DRB, and may also be referred to as a "PDCP configuration information element." Information elements related to the configuration of the E-UTRA PDCP entity may include an information element indicating the size of the sequence number, an information element indicating the profile of header compression (RoHC), and reordering timer information.

[0163] also, Figure 7 or Figure 8 Some or all of the information elements shown may be optional. Figure 7 or Figure 8 The information elements shown may be included in a message related to the reconfiguration of an RRC connection, as needed and conditional. Furthermore, in addition to information elements related to the configuration of radio bearers, a message related to the reconfiguration of an RRC connection may also include an information element indicating the application of full configuration. This information element indicating the application of full configuration may be represented by an information element name such as "fullConfig," or by using "true," "enable," or other similar information elements to indicate the application of full configuration.

[0164] The information element represented by DRB-ToReleaseList included in the information element represented by RadioResourceConfigDedicated may include information indicating one or more DRB identifiers to be released.

[0165] Next, use Figures 9 to 11An example of a method for processing an Ethernet header compression protocol according to an embodiment of the present invention will be described. It should be noted that the aforementioned Ethernet header compression protocol may also be referred to as Ethernet header compression processing. Furthermore, Ethernet header compression processing may also be performed based on the fact that an RRC message sent from the base station apparatus to the UE 122 includes an information element or field indicating the application of Ethernet header compression and / or an information element or field indicating an Ethernet PDU session. In this example, an example of Ethernet header compression being performed in a PDCP entity is shown, but it may also be performed in entities at other layers. Furthermore, the base station apparatus may be either an eNB 102 or a gNB 108, but to avoid cumbersome descriptions, the following description uses gNB 108. Furthermore, in an embodiment of the present invention, the Ethernet header may also be part or all of the communication control information included in an Ethernet frame. Furthermore, in an embodiment of the present invention, the Ethernet frame may also be in the IEEE 802.1 MAC (Medium Access Control) frame format as described in IEEE documents such as Non-Patent Document 19.

[0166] Figure 9 is an example of an ASN.1 description including an information element or field indicating the application of Ethernet header compression in an RRC message sent from gNB 108 to UE 122. In addition, Figure 10 is an example of an ASN.1 description of an information element or field representing an Ethernet PDU session in an RRC message sent from gNB 108 to UE 122. Figure 7 and Figure 8 Similarly, in the examples of ASN.1, <Omitted> and <Omitted> indicate the omission of other information, rather than the omission of a part of the ASN.1 expression. It should be noted that in places where there is no such record as <Omitted> or <Omitted>, the information element can also be omitted. It should be noted that the example of ASN.1 does not correctly follow the ASN.1 expression method, but is an example of the parameters of the RRC message of the embodiment of the present invention. Other names and other expressions may also be used. In addition, the example of ASN.1 only shows an example of the main information closely related to one scheme of the present invention. It should be noted that sometimes the parameters described in ASN.1 are not distinguished from fields, information elements, etc., and all are referred to as information elements. In addition, in the embodiments of the present invention, the parameters such as fields and information elements described in ASN.1 included in the RRC message are sometimes referred to as information.

[0167] Figure 9 Show Figure 7 and / or Figure 8The PDCP settings information element in includes an example of an information element or field indicating that Ethernet header compression is applied. Figure 9 In the PDCP setting information element, the field or information element shown with the name ethernetHeaderCompression-r16 included is a field or information element used to make settings related to the Ethernet header compression protocol. Hereinafter, the field or information element used to make settings related to the Ethernet header compression protocol is sometimes referred to as the Ethernet Header Compression Setting or EHC (Ethernet Header Compression) Setting. The Ethernet Header Compression Setting may also exist only when the PDCP entity for the DRB associated with the Ethernet PDU session is established, and does not exist in other cases. The field or information element shown with the name notUsed included in the Ethernet Header Compression Setting may also be a field or information element indicating that Ethernet header compression is not applied or that Ethernet header compression is not set. The field or information element shown with the name ehc included in the Ethernet Header Compression Setting may be information indicating that Ethernet header compression is applied or that Ethernet header compression is set, or may include information required for applying Ethernet header compression. The above-mentioned information required for applying Ethernet header compression may be, for example, the maximum value of a context identifier (CID: Context IDentity or Context IDentifier). The maximum value of the context identifier can be either the maximum value of a non-negative integer or a positive integer that can be used as a context identifier, or the upper limit of the number of integers that can be used as context identifiers. Figure 9 In the example of , the field named ehc-maxCID indicates the maximum value of the context identifier. Figure 9In the example, the maximum value of the context identifier can be an integer from 1 to 127, and 15 is specified as the default value, but this value is not required. Furthermore, when the maximum value of the context identifier is "0" or "1," it may indicate that Ethernet header compression is not applied. Furthermore, the sum of the maximum values ​​of the context identifiers in all DRBs for a PDU session may not exceed the maximum number of context identifiers per PDU session or per UE that UE 122 sends to the gNB as a UE capability. It should be noted that the context identifier may also be an identifier used to uniquely identify information required for Ethernet header compression and / or decompression. Furthermore, the information required for Ethernet header compression and / or decompression may also be part or all of the Ethernet header information. Furthermore, part or all of the Ethernet header information may also be information within the Ethernet header that is subject to Ethernet header compression. Furthermore, the information required for Ethernet header compression and / or decompression may also be referred to as a context. Alternatively, it may be a profile for Ethernet header compression. Figure 9 The information element or field shown by the name of ehc-profiles may also be an information element representing the profile of the above-mentioned Ethernet header compression. The above-mentioned Ethernet header compression profile may also represent an Ethernet header compression method. The above-mentioned Ethernet header compression method may also be a method of specifying which field of the header is to be compressed. In the relationship between the above-mentioned Ethernet header compression profile and the above-mentioned Ethernet header compression method, for example, when there are three fields A, B and C in the Ethernet header, profile 1 indicates that only A is compressed, profile 2 indicates that only A and B are compressed, and profile 3 indicates that A, B and C are compressed. It may also be a relationship. In addition, the information element or field representing the above-mentioned profile 1 may also be represented by Figure 9 The information element or field represented by the name ehc-profile0x0001 is shown. In addition, the information element or field representing the above-mentioned profile 2 can also be represented by Figure 9 The information element or field represented by the name of ehc-profile0x0002 is shown. In addition, the information element or field representing the above-mentioned profile 3 can also be represented by Figure 9The information element or field named ehc-profile0x0003 is shown. In addition, the above-mentioned Ethernet header compression profile may also indicate the type of Ethernet frame format. The type of Ethernet frame format may also be Ethernet2, Ethernet2+802.1Q tag, Ethernet2+802.1Q tag+802.1Q tag, etc., as shown in IEEE documents such as Non-Patent Document 19. In addition, the above-mentioned Ethernet header compression profile may also be information indicating a combination of the above-mentioned Ethernet header compression method, the above-mentioned Ethernet frame format type, and part or all of other information. UE122 sets Ethernet header compression based on the fact that the RRC message received from gNB108 includes information indicating the above-mentioned Ethernet header compression or indicating the setting of Ethernet header compression. In addition, the above-mentioned information required for applying Ethernet header compression may also be available context identifier information (not shown). The available context identifier information may be given in a range of, for example, "10 to 20" or may specify a value such as "5, 10, 15, 20".

[0168] It should be noted that Figure 9 Part or all of the fields and information elements in the may also be configured for transmission (uplink) and / or reception (downlink), respectively. That is, different information elements or fields may be used for uplink and downlink.

[0169] Figure 10 Show Figure 7 The SDAP configuration information element includes an example of an information element or field representing an Ethernet PDU session. Figure 10 In the , the field or information element shown with the name ethernetPduSession-r16 may also be a field or information element indicating whether the PDU session associated with the SDAP entity established and / or set by this SDAP setting information element is an Ethernet PDU session or whether it is an Ethernet PDU session. It may be that if the field or information element shown with the name ethernetPduSession-r16 is true (true), it indicates an Ethernet PDU session. In addition, in Figure 10 middle, Figure 9The fields or information elements for configuring the Ethernet header compression protocol may also be present only when the information indicating an Ethernet PDU session is included. It should be noted that when the RRC message received from gNB 108 includes the aforementioned information element or field indicating an Ethernet PDU session, the SDAP entity of UE 122 may treat the upper layer as the Ethernet layer and may also pass the SDAP SDU, after processing the SDAP PDU received from the lower layer, to the Ethernet layer.

[0170] Figure 11 This is an example of a processing method for the Ethernet header compression protocol of an embodiment of the present invention. The PDCP entity of UE122 confirms the Ethernet header of the PDCP SDU received from the upper layer, and stores the above-mentioned Ethernet header information that is the object of compression as the context without storing the information of the Ethernet header that is the object of compression as the context together with the context identifier, and establishes an association with the context identifier. The context identifier and the context can be associated one-to-one. In addition, the above-mentioned context identifier can also be included in the above-mentioned context. Then, the PDCP entity of UE122 can also attach any one or all of the context identifier indicating that the association is established, the information that the Ethernet header is not compressed or changed, and other information to the above-mentioned PDCP SDU, and submit it to the lower layer. In addition, the PDCP entity of UE122 can also confirm the Ethernet header of the PDCP SDU received from the upper layer, and when the same information as the Ethernet header information to be compressed is stored as the context together with the context identifier and / or when feedback indicating that Ethernet header compression is permitted (or indicating that the context is correctly stored) is received from the PDCP entity corresponding to gNB108, the above-mentioned Ethernet header information to be compressed is deleted from the above-mentioned PDCP SDU, and any one or all of the information indicating that an associated context identifier is established, information indicating that the Ethernet header is compressed or changed, and other information is added, and submitted to the lower layer (step S1100).

[0171] Furthermore, when a PDCP PDU received from a lower layer explicitly or implicitly includes information indicating that the Ethernet header is not compressed or modified, the PDCP entity of UE 122 may associate the Ethernet header information included in the Ethernet header included in the PDCP PDU with the context identifier included in the PDCP PDU and store the information as a context. During storage, feedback indicating that Ethernet header compression is permitted (or indicating that the context is correctly stored) may be sent to the PDCP entity corresponding to gNB 108. Furthermore, when a PDCP PDU received from a lower layer explicitly or implicitly includes information indicating that the Ethernet header is compressed or modified, the PDCP entity of UE 122 may not decompress the Ethernet header and instead hand over the PDCP SDU to the upper layer. In addition, when the PDCP PDU received from the lower layer explicitly or implicitly includes information indicating that the Ethernet header is compressed or changed, the PDCP entity of UE122 can also decompress the Ethernet header according to the stored context information and hand over the PDCP SDU to the upper layer (step S1102).

[0172] It should be noted that the Ethernet header information to be compressed can be all of the Ethernet header information or only a portion of the Ethernet header information. Furthermore, the Ethernet header compression protocol described above is merely an example and may not be performed in this order. Furthermore, steps S1100 and S1102 may be performed in any order, and may be performed as independent steps.

[0173] use Figure 12 A first example of a processing method of UE 122 according to an embodiment of the present invention will be described. Figure 12 The outline of the processing method of UE122 of the embodiment of the present invention shown is a process in which UE122 releases or deletes a stored context based on the information of the released or deleted context sent from gNB108. For example, when the QoS flow corresponding to the DRB is released, gNB108 may send the information of the released or deleted context to UE122 in order to release the context corresponding to the Ethernet flow associated with the released QoS flow from UE122. In addition, when there is no fixed time for sending and / or receiving the Ethernet frame corresponding to the context stored in UE112, gNB108 may send the information of the released or deleted context to UE122 in order to release the context from UE122. It should be noted that Figure 12The processing of UE 122 in the embodiment of the present invention shown may also be performed when Ethernet header compression is set. It should be noted that the above-mentioned Ethernet flow may refer to Ethernet frames that have the same sender MAC address, destination MAC address, and other Ethernet header information, in part or in whole.

[0174] exist Figure 12 In the process, the processing unit 602 of gNB108 generates an RRC message for UE122 to process, and the sending unit 600 sends it to UE122 (not shown). The receiving unit 500 of UE122 receives the RRC message from gNB108 (step S1200). It should be noted that the above-mentioned RRC message can be either a message related to the re-setting of the RRC connection or other messages. In addition, the above-mentioned message related to the re-setting of the RRC connection can also be a message named RRC re-setting message recorded in non-patent document 10. It should be noted that UE122 can also receive the above-mentioned message related to the re-setting of the RRC connection from eNB102. In this case, the message related to the re-setting of the RRC connection can also be a message named RRC connection re-establishment message recorded in non-patent document 4.

[0175] Next, the processing unit 502 of UE122 confirms whether the above-mentioned RRC message includes information related to the released context. In the case where the information related to the released context is included, the corresponding context is released based on the case where the information related to the released context is included (step S1202). It should be noted that the above-mentioned context can also be associated with a context identifier for identifying the context. In addition, the above-mentioned context identifier and the above-mentioned context can be associated one-to-one. In addition, the above-mentioned information related to the released context can be a context identifier associated with the corresponding context. In addition, the above-mentioned information related to the released context can also be set to be able to release multiple contexts by making a list of context identifiers.

[0176] It should be noted that the aforementioned context may also be all Ethernet header information in an Ethernet frame. Furthermore, the aforementioned context identifier may also be an identifier used for Ethernet header compression. Furthermore, the aforementioned context may also be a RoHC context, and the aforementioned context identifier may also be a context identifier in RoHC.

[0177] In addition, the above-mentioned information related to the released context can also be divided into information related to the released context for uplink transmission and information related to the released context for downlink reception.

[0178] In addition, the above-mentioned information related to the release context may also be included in Figure 7and / or Figure 8 In step S1202, when releasing the corresponding context based on the information related to the released context, the context may be released in the following order.

[0179] (A) The RRC layer of UE122 notifies the lower layer or the PDCP entity of the above-mentioned information related to the released context based on the fact that the value of the radio bearer identifier information element (or radio bearer identifier field) included in the received RRC message exists as the current setting of UE122 and the fact that the received RRC message includes the information related to the released context.

[0180] (B) In the PDCP entity, the upper layer or the RRC layer releases the corresponding context based on a request for context release.

[0181] It should be noted that the RRC layer of UE122 may also, based on the fact that the value of the radio bearer identifier information element (or radio bearer identifier field) included in the received RRC message exists as the current setting of UE122 and the received RRC message includes a PDCP setting information element, reconfigure the PDCP entity according to the above-mentioned PDCP setting information element, instead of the above-mentioned processing (A). In addition, in the PDCP entity, the upper layer or the RRC layer may release the corresponding context based on the situation that the context identifier of the released context is received, instead of the above-mentioned processing (B). In addition, the above-mentioned processing B may also be performed in the Ethernet header compression protocol of the PDCP entity.

[0182] It should be noted that the PDCP entity of UE 122 may also receive the above-mentioned information related to the released context from the SDAP entity.

[0183] It should be noted that, in step S1202, release may also mean deletion. The term release in step S1102 may also be replaced by deletion or an equivalent term.

[0184] Figure 13 is an example of an ASN.1 description of the information related to the released or deleted context included in the RRC message received by UE122 from gNB108 in step S1200 above. Figure 7 、 Figure 8 、 Figure 9 as well as Figure 10Similarly, in the examples of ASN.1, <Omitted> and <Omitted> indicate the omission of other information, rather than the omission of a part of the ASN.1 expression. It should be noted that in places where there is no such record as <Omitted> or <Omitted>, the information element can also be omitted. It should be noted that the example of ASN.1 does not correctly follow the ASN.1 expression method, but is an example of the parameters of the RRC message of the embodiment of the present invention. Other names and other expressions may also be used. In addition, the example of ASN.1 only shows an example of the main information closely related to one scheme of the present invention. It should be noted that sometimes the parameters described in ASN.1 are not distinguished from fields, information elements, etc., and all are referred to as information elements. In addition, in the embodiments of the present invention, the parameters such as fields and information elements described in ASN.1 included in the RRC message are sometimes referred to as information.

[0185] Figure 13 Show Figure 7 and / or Figure 8 Examples of information elements or fields related to released or deleted contexts are included in the PDCP setup information element in FIG. Figure 13 In the PDCP configuration information element, the field or information element named ehc-contextToReleaseList-r16 may also be an information element or field indicating a list of context identifiers of contexts to be released or deleted. Figure 13 In the example of , the information element or field indicated by the name EHC-CID may also be an information element or field indicating a context identifier. Figure 13 The information element or field denoted by the name ehc-maxCID may also be used with Figure 9 The information element or field indicating the context identifier may be an integer from 1 to ehc-maxCID.

[0186] It should be noted that Figure 13 Some or all of the fields and information elements in the may be set for transmission (uplink) and / or reception (downlink), respectively. Different information elements or fields may also be used for uplink and downlink.

[0187] use Figure 14 A second example of the processing method of UE 122 according to the embodiment of the present invention will be described. Figure 14The outline of the processing method of UE122 of the embodiment of the present invention shown may also be that UE122 starts or restarts the context deletion timer each time it receives a PDCP SDU with the same context information (part or all of the information in the Ethernet header) from the upper layer, and deletes the corresponding context when the timer expires. In addition, UE122 may also start or restart the context deletion timer each time it receives a PDCP PDU with the same context identifier from the lower layer, and delete the corresponding context when the timer expires. The value of the context deletion timer may also be included in the RRC message received from gNB108. It should be noted that Figure 14 The processing of UE 122 in the illustrated embodiment of the present invention may also be performed when Ethernet header compression is set.

[0188] exist Figure 14 In the example, processing unit 602 of gNB 108 generates an RRC message for UE 122 to process, and transmitting unit 600 transmits the message to UE 122 (not shown). The RRC layer of UE 122 checks whether the RRC message received from gNB 108 includes an information element or field related to a timer for managing the context. The aforementioned timer for managing the context can also be referred to as a timer for releasing or deleting the context. If the information element or field related to a timer for managing the context is included, the RRC layer of UE 122 can also request the PDCP entity of UE 122 to use the timer for managing the context (step S1400).

[0189] It should be noted that in step S1400, the RRC layer of UE122 may also set the timer for managing the context in the PDCP entity of UE122 when the RRC message received from gNB108 includes an information element or field related to the timer for managing the context.

[0190] The PDCP entity of UE122 confirms the Ethernet header of the PDCP SDU received from the upper layer and confirms whether the information of the Ethernet header that is subject to compression is stored as a context. Alternatively, when the information of the Ethernet header that is subject to compression of the Ethernet header of the PDCP SDU is not stored as a context, the Ethernet header information that is subject to compression may be associated with a context identifier and stored as a context, and a timer for managing the context may be set for the stored context or the context identifier, and the timer may be started or restarted. In addition, instead of setting a timer for managing the context for the stored context and starting or restarting the timer, a timer for managing the context may be set for the context identifier associated with the stored context and the timer may be started or restarted. It should be noted that the setting of the timer for managing the context may also be performed by the RRC layer or an upper layer. In addition, the setting of the timer for managing the context may not be performed. Furthermore, the PDCP entity of UE 122 may also start or restart a timer for managing the context, which is set or operated for the stored context and / or the context identifier associated with the stored context, when storing information of the Ethernet header of the PDCP SDU that is the target of compression as a context. Furthermore, the PDCP entity of UE 122 may also release or delete the context and / or the context identifier associated with any of the contexts, when the timer for managing the context, which is set or operated for the stored context or the context identifier associated with the stored context expires (step S1402).

[0191] Furthermore, the PDCP entity of UE 122 confirms whether the PDCP PDU received from the lower layer explicitly or implicitly includes information indicating that the Ethernet header is not compressed or changed. Alternatively, if the PDCP PDU explicitly or implicitly includes information indicating that the Ethernet header is not compressed or changed, the Ethernet header information included in the Ethernet header of the PDCP PDU that is subject to compression is used as a context, associated with the context identifier included in the PDCP PDU, and stored. A timer for managing the context is set for the stored context or the context identifier, and the timer is started or restarted. Furthermore, instead of setting a timer for managing the context for the stored context and starting or restarting the timer, a timer for managing the context is set for the context identifier associated with the stored context, and the timer is started or restarted. It should be noted that the setting of the timer for managing the context may also be performed by the RRC layer or an upper layer. Furthermore, the setting of the timer for managing the context may not be performed. Furthermore, the PDCP entity of UE 122 may also start or restart a timer for managing a context for the context identifier included in the PDCP PDU or a context associated with the context identifier, if the PDCP PDU explicitly or implicitly includes information indicating that the Ethernet header is compressed or changed. Furthermore, the PDCP entity of UE 122 may also release or delete the context and / or the context identifier associated with any of the contexts if a timer for managing a context set or operated for the context or the context identifier associated with the context expires (step S1404).

[0192] It should be noted that in step S1404, the PDCP entity of UE 122 may also confirm whether a context associated with the context identifier included in the PDCP PDU received from the lower layer is stored, instead of confirming whether the PDCP PDU received from the lower layer explicitly or implicitly includes information indicating that the Ethernet header is not compressed or modified. Alternatively, if no context associated with the context identifier included in the PDCP PDU is stored, the PDCP entity may associate and store the Ethernet header information in the Ethernet header included in the PDCP PDU that is subject to compression as a context, set a timer for managing the context for the stored context or the context identifier, and start or restart the timer. Furthermore, if a context associated with the context identifier included in the PDCP PDU is stored, the PDCP entity may start or restart a timer for managing the context that was set or running for the stored context and / or the context identifier associated with the context.

[0193] It should be noted that in step S1402 and / or step S1404, the timer for managing the context can also be managed independently for each context and / or each context identifier. That is, a timer for managing the first context and / or the first context identifier, and a timer for managing the second context for the second context and / or the second context identifier can be set independently. The timer for managing the first context and / or the first context identifier, and the timer for managing the second context for the second context and / or the second context identifier can also be started or restarted independently. Furthermore, upon expiration of the timer for managing the first context, the first context and / or the first context identifier can be released or deleted. Upon expiration of the timer for managing the second context, the second context and / or the second context identifier can also be released or deleted.

[0194] It should be noted that in step S1402 and / or step S1404, all timers can be restarted when gNB108 sets a new timer value for the timer used to manage the context. No operation can be performed on the timer that is in operation, and a new timer value can be set for the timer set when the new context is stored.

[0195] It should be noted that, in the embodiment of the present invention, starting the timer may also mean running the timer.

[0196] It should be noted that the processing of step S1402 and / or step 1404 can be performed based on the case where the PDCP entity of UE 122 is requested by the RRC layer or a higher layer to use a timer for managing the context. In addition, the processing of step S1402 and / or step 1404 can also be performed based on the case where the PDCP entity of UE 122 is set with a timer for managing the context by the RRC layer or a higher layer.

[0197] It should be noted that there may be no sequential relationship between step S1402 and step S1404, and step S1402 and step S1404 may also be performed as independent steps.

[0198] It should be noted that the processing of step S1402 and step S1404 can also be performed in conjunction with the processing of step S1100 and step S1102 described above.

[0199] Figure 15 yes Figure 7 and / or Figure 8 An example of an ASN.1 description of information elements or fields related to timers used to manage contexts included in the PDCP configuration information element in . Figure 15 In the PDCP configuration information element, the field or information element named ehcContextDiscardTimer-16 included in the PDCP configuration information element may also be an information element or field related to the timer for managing the context. Figure 15 In the example, the field or information element named ehcContextDiscardTimer-16 may exist only during setup. Figure 15 In the example, the field or information element named ehcContextDiscardTimer-16 can also take any value of s1, s2, s3, s5, s7, s10, s15, s20, s40, s50, s60, s80, s100, s120, s150, or s180. The parameter denoted by sN (N is a natural number) can also mean N seconds (N second(s)).

[0200] It should be noted that Figure 15 Some or all of the fields and information elements in the may be set for transmission (uplink) and / or reception (downlink), respectively. Different information elements or fields may also be used for uplink and downlink.

[0201] use Figure 9 and Figure 16 A third example of the processing method of UE 122 according to the embodiment of the present invention will be described. Figure 16 The outline of the processing method of UE122 of the embodiment of the present invention shown may also be that when UE122 wants to store a new context for a PDCP SDU received from an upper layer and there is no available context identifier, that is, when the number of contexts stored in UE122 reaches the maximum value of context identifiers set by gNB108, UE122 will assign a context identifier associated with any stored context to a new context. In this case, the old context may be overwritten with the new context. In addition, UE122 has already stored a context associated with the context identifier included in the PDCP PDU received from a lower layer, but when the above-mentioned PDCP PDU explicitly or implicitly includes information indicating that the Ethernet header is not compressed or changed, the stored context may be overwritten with the Ethernet header information that is the object of compression in the Ethernet header included in the above-mentioned PDCP PDU.

[0202] exist Figure 16 In the example, the processing unit 602 of gNB108 generates an RRC message for UE122 to process, and the transmitting unit 600 transmits the message to UE122 (not shown). UE122 sets the maximum value of the context identifier based on the information element or field indicating the maximum value of the context identifier included in the RRC message received from gNB108. It should be noted that the above-mentioned context identifier can also be Figure 9 The maximum value of the context identifier may be set using different fields or information elements for the maximum value of the uplink context identifier and the maximum value of the downlink context identifier (step S1600).

[0203] The PDCP entity of UE 122 examines the Ethernet header of the PDCP SDU received from an upper layer and checks whether information about the Ethernet header that is a target for compression is stored as a context. If the Ethernet header information of the Ethernet header of the PDCP SDU that is a target for compression is not stored as a context and the number of currently stored contexts has reached a set maximum number of context identifiers, the PDCP entity of UE 122 may associate one of the context identifiers associated with the currently stored context with a new Ethernet flow, that is, associate it with the Ethernet header information of the Ethernet header of the PDCP SDU that is a target for compression, and store it as a new context. In this case, the context associated with the context identifier may be overwritten with the new context. Furthermore, if the Ethernet header information of the Ethernet header of the PDCP SDU that is a target for compression is not stored as a context and the number of currently stored context identifiers has reached a set maximum number of context identifiers, the PDCP entity of UE 122 may not store the Ethernet header information of the Ethernet header that is a target for compression as a context and may not send the Ethernet header compression (step S1602). It should be noted that the above-mentioned Ethernet stream may also refer to Ethernet frames having part or all of the same Ethernet header information.

[0204] Furthermore, the PDCP entity of UE 122 confirms whether the PDCP PDU received from the lower layer explicitly or implicitly includes information indicating that the Ethernet header is not compressed or modified. If the PDCP PDU explicitly or implicitly includes information indicating that the Ethernet header is not compressed or modified, and the value of the context identifier included in the PDCP PDU is already associated with a stored context, the PDCP entity of UE 122 may overwrite the context associated with the context identifier with the Ethernet header information that is a target for compression included in the Ethernet header of the PDCP PDU received from the lower layer (step S1604).

[0205] It should be noted that there may be no sequential relationship between step S1602 and step S1604, and step S1602 and step S1604 may also be performed as independent steps.

[0206] It should be noted that in steps S1602 and / or S1604 above, in order to distinguish PDCP PDUs to which Ethernet header compression is applied from PDCP PDUs to which Ethernet header compression is not applied, a context identifier with a specific value may be used for PDCP PDUs to which Ethernet header compression is not applied. For example, a context identifier of zero may be set to indicate that Ethernet header compression is not applied. Furthermore, the context identifier indicating that Ethernet header compression is not applied may also be set by gNB 108 via an RRC message. Furthermore, instead of using a specific context identifier indicating that Ethernet header compression is not applied, information indicating that Ethernet header compression is not applied may be appended to the PDCP PDU. This information indicating that Ethernet header compression is not applied may be appended to either the PDCP header or the payload portion of the PDCP PDU.

[0207] It should be noted that, in the embodiment of the present invention, the processing of step S1102, step S1404, and step S1604 may also be performed only on the PDCP PDU to which Ethernet header compression is applied.

[0208] In addition, in the embodiment of the present invention, the processing of step S1100 and step S1402 may also be performed only on the PDCP SDU to which Ethernet header compression is applied.

[0209] It should be noted that part or all of the processing of an example of the Ethernet header compression protocol processing method of an embodiment of the present invention, the first example of the processing method of UE122, the second example of the processing method of UE122, and the third example of the processing method of UE122 can also be performed in a linked manner.

[0210] It should be noted that the Ethernet header information to be compressed in the embodiment of the present invention may be all of the Ethernet header information or a portion of the Ethernet header information.

[0211] It should be noted that, in the embodiment of the present invention, the Ethernet header information to be compressed is stored as the context, or the context identifier is associated with the Ethernet header information to be compressed. In addition, in the embodiment of the present invention, the context identifier may also be part of the context.

[0212] Furthermore, in the embodiments of the present invention, the storage of the context may be referred to as the generation of the context, or as the establishment of the context, or as other terms.

[0213] Furthermore, in the embodiments of the present invention, implicitly including information indicating that the Ethernet header is compressed or modified may also mean not including information indicating that the Ethernet header is not compressed or modified. Furthermore, implicitly including information indicating that the Ethernet header is not compressed or modified may also mean not including information indicating that the Ethernet header is compressed or modified.

[0214] Furthermore, in the Ethernet header compression process of the embodiment of the present invention, the processing on the transmitting side may be performed by a compressor of the Ethernet header compression protocol, and the processing on the receiving side may be performed by a decompressor of the Ethernet header compression protocol.

[0215] Furthermore, in the embodiments of the present invention, Ethernet header compression is described, but part or all of the processing in the embodiments of the present invention may also be applied to other header compression technologies, such as RoHC.

[0216] In the above description, expressions such as "associated", "established a correspondence", and "established an association" can also be replaced with each other.

[0217] It should be noted that in the above description, "A may be replaced by B" or "A may be B" may not only mean that A may be replaced by B or A may be set to B, but also mean that B may be replaced by A or B may be set to A. Furthermore, in the above description, when "C may also be D" and "C may also be E" are stated, "D may also be E" is also included. Furthermore, in the above description, when "F may also be G" and "G may also be H" are stated, "F may also be H" is also included.

[0218] Hereinafter, various aspects of the embodiments of the present invention will be described.

[0219] One embodiment of the present invention is a terminal device for communicating with a base station device, comprising: a receiving unit for receiving an RRC message from the base station device; and a processing unit for deleting the context identifier and a context associated with the context identifier, based on the fact that the RRC message includes a context identifier for a released context. It should be noted that the context identifier is used for Ethernet header compression, and the context is part or all of Ethernet header information.

[0220] In addition, one embodiment of the present invention is a terminal device that communicates with a base station device, comprising: a receiving unit that receives an RRC message from the base station device; and a processing unit that, based on the fact that the RRC message includes information for setting a context management timer, generates a first context related to a header included in the first service data unit when a first service data unit is received from an upper layer, and starts or restarts a first timer for the first context when the first context related to the header included in the first service data unit is not stored; starts or restarts the first timer when the first context related to the header included in the first service data unit is stored, and deletes the first context based on the expiration of the first timer.

[0221] In addition, one embodiment of the present invention is a terminal device that communicates with a base station device, comprising: a receiving unit that receives an RRC message from the base station device; and a processing unit that, based on the fact that the RRC message includes information for setting a context management timer, generates a second context related to a header included in the second protocol data unit when a second protocol data unit is received from a lower layer, and starts or restarts a second timer for the second context when the second protocol data unit includes information indicating that header compression is not performed on the second protocol data unit, starts or restarts the second timer when the RRC message includes information indicating that header compression is performed on the second protocol data unit, and deletes the second context based on the expiration of the second timer.

[0222] In addition, one embodiment of the present invention is a terminal device that communicates with a base station device, has a processing unit, receives an RRC message including a maximum value of a context identifier from the base station device, and when a third service data unit is received from an upper layer, when a third context related to a header included in the third service data unit is not stored and the number of stored contexts reaches the maximum value of the context identifier, assigns a fourth context identifier associated with one of the stored contexts to the third context.

[0223] Furthermore, one embodiment of the present invention is a base station device for communicating with a terminal device, comprising: a transmitter for transmitting an RRC message to the terminal device; and a processor for causing the terminal device to perform processing to delete the context identifier and a context associated with the context identifier, based on the fact that the RRC message includes a context identifier for a released context. It should be noted that the context identifier is used for Ethernet header compression, and the context is part or all of Ethernet header information.

[0224] In addition, one embodiment of the present invention is a base station device that communicates with a terminal device, comprising: a sending unit that sends an RRC message to the terminal device; and a processing unit that enables the terminal device to perform processing based on the information for setting a context management timer included in the RRC message. When a first service data unit is received from an upper layer, if the first context related to the header included in the first service data unit is not stored, the terminal device generates a first context related to the header included in the first service data unit, starts or restarts a first timer for the first context, and starts or restarts the first timer when the first context related to the header included in the first service data unit is stored, and deletes the first context based on the expiration of the first timer.

[0225] In addition, one embodiment of the present invention is a base station device that communicates with a terminal device, comprising: a sending unit that sends an RRC message to the terminal device; and a processing unit that causes the terminal device to perform processing based on the fact that the RRC message includes information for setting a context management timer. When a second protocol data unit is received from a lower layer, the terminal device generates a second context related to a header included in the second protocol data unit, starts or restarts a second timer for the second context, starts or restarts the second timer, and deletes the second context based on the expiration of the second timer.

[0226] In addition, one embodiment of the present invention is a base station device that communicates with a terminal device, comprising a processing unit that sends an RRC message including a maximum value of a context identifier to the terminal device, so that the terminal device, when receiving a third service data unit from an upper layer, assigns a fourth context identifier associated with one of the stored contexts to the third context when a third context related to a header included in the third service data unit is not stored and the number of stored contexts reaches the maximum value of the context identifier.

[0227] Furthermore, one embodiment of the present invention is a method for a terminal device communicating with a base station device, wherein the method comprises: receiving an RRC message from the base station device; and, based on the fact that the RRC message includes a context identifier of a released context, deleting the context identifier and a context associated with the context identifier. It should be noted that the context identifier is used for Ethernet header compression, and the context is part or all of Ethernet header information.

[0228] In addition, one embodiment of the present invention is a method for a terminal device communicating with a base station device, wherein an RRC message is received from the base station device, and based on the fact that the RRC message includes information for setting a context management timer, when a first service data unit is received from an upper layer, a first context related to a header included in the first service data unit is generated without storing a first context related to the header included in the first service data unit, and a first timer for the first context is started or restarted; when the first context related to the header included in the first service data unit is stored, the first timer is started or restarted, and the first context is deleted based on the expiration of the first timer.

[0229] In addition, one embodiment of the present invention is a method for a terminal device communicating with a base station device, wherein an RRC message is received from the base station device, and based on the fact that the RRC message includes information for setting a context management timer, when a second protocol data unit is received from a lower layer, a second context related to a header included in the second protocol data unit is generated, and a second timer for the second context is started or restarted when the information indicating that the header compression of the second protocol data unit is included is included, and the second timer is started or restarted when the information indicating that the header compression of the second protocol data unit is included is included, and the second context is deleted based on the expiration of the second timer.

[0230] In addition, one embodiment of the present invention is a method for a terminal device communicating with a base station device, wherein an RRC message including a maximum value of a context identifier is received from the base station device, and when a third service data unit is received from an upper layer, a fourth context identifier associated with one of the stored contexts is assigned to the third context when a third context related to a header included in the third service data unit is not stored and the number of stored contexts reaches the maximum value of the context identifier.

[0231] Furthermore, one embodiment of the present invention is a method for a base station device communicating with a terminal device, wherein an RRC message is sent to the terminal device, causing the terminal device to delete the context identifier and a context associated with the context identifier based on the fact that the RRC message includes a context identifier for a released context. It should be noted that the context identifier is used for Ethernet header compression, and the context is part or all of Ethernet header information.

[0232] In addition, one embodiment of the present invention is a method for a base station device to communicate with a terminal device, wherein an RRC message is sent to the terminal device, so that the terminal device performs, based on the information for setting a context management timer included in the RRC message, when a first service data unit is received from an upper layer, generating a first context related to a header included in the first service data unit without storing a first context related to the header included in the first service data unit, and starting or restarting a first timer for the first context; starting or restarting the first timer when the first context related to the header included in the first service data unit is stored, and deleting the first context based on the expiration of the first timer.

[0233] In addition, one embodiment of the present invention is a method for a base station device communicating with a terminal device, wherein an RRC message is sent to the terminal device, so that the terminal device performs processing based on the fact that information for setting a context management timer is included in the RRC message. When a second protocol data unit is received from a lower layer, the terminal device generates a second context related to a header included in the second protocol data unit, starts or restarts a second timer for the second context, starts or restarts the second timer, and deletes the second context based on the expiration of the second timer.

[0234] In addition, one embodiment of the present invention is a method for a base station device to communicate with a terminal device, wherein an RRC message including a maximum value of a context identifier is sent to the terminal device, so that the terminal device performs processing of assigning a fourth context identifier associated with one of the stored contexts to the third context when receiving a third service data unit from an upper layer, when a third context related to a header included in the third service data unit is not stored and the number of stored contexts reaches the maximum value of the context identifier.

[0235] The program running in the device of one embodiment of the present invention may be a program that controls a central processing unit (CPU) and other devices to implement the functions of the aforementioned embodiment of one embodiment of the present invention, thereby enabling the computer to function. During processing, the program or the information processed by the program is temporarily read into volatile memory such as random access memory (RAM), or stored in non-volatile memory such as flash memory, or a hard disk drive (HDD). The CPU then reads, modifies, or writes to the program as needed.

[0236] It should be noted that a portion of the device in the above embodiment can be implemented by a computer. In this case, the program for implementing the control function can be recorded on a computer-readable recording medium, and the program recorded on the recording medium can be read into a computer system and executed. The "computer system" mentioned here refers to a computer system built into the device, and is set to include hardware such as an operating system and peripherals. In addition, the "computer-readable recording medium" can be any one of a semiconductor recording medium, an optical recording medium, a magnetic recording medium, etc.

[0237] Furthermore, "computer-readable recording media" may include media that dynamically store programs for a short period of time, such as a communication line when transmitting a program via a network such as the Internet or a communication line such as a telephone line, or media that store programs for a fixed period of time, such as volatile memory within a computer system serving as a server or client in this case. Furthermore, the program may be a program for implementing a portion of the functions described above, or a program that can achieve the functions described above by combining it with a program already stored in the computer system.

[0238] In addition, each functional block or each feature of the device used in the above-mentioned embodiment can be implemented or executed by a circuit, that is, typically by an integrated circuit or multiple integrated circuits. Circuits designed in a manner to perform the functions described in this specification may include: a general-purpose processor, a digital signal processor (DSP), an integrated circuit for a specific purpose (ASIC), a field programmable gate array (FPGA) or other programmable logic elements, discrete gates or transistor logic, discrete hardware parts or a combination thereof. The general-purpose processor may be a microprocessor, or the processor may instead be an existing processor, controller, microcontroller or state machine. The general-purpose processor or the circuits described above may be composed of digital circuits or analog circuits. In addition, in the case where integrated circuit technology that replaces existing integrated circuits appears with the advancement of semiconductor technology, integrated circuits based on this technology may also be used.

[0239] It should be noted that the present invention is not limited to the aforementioned embodiments. While the embodiments describe an example of a device, the present invention is not limited thereto and can be applied to fixed or non-movable electronic devices installed indoors or outdoors, such as AV equipment, kitchen appliances, cleaning / washing equipment, air conditioners, office equipment, vending machines, and other household appliances, such as terminal devices or communication devices.

[0240] While the embodiments of the present invention have been described in detail above with reference to the accompanying drawings, the specific configuration is not limited to this embodiment and also includes design changes within the scope of the present invention. In addition, one embodiment of the present invention can be modified in various ways within the scope of the technical solution, and embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also included in the technical scope of the present invention. In addition, configurations obtained by replacing elements that have the same effect as those described in the above embodiments with each other are also included.

[0241] Industrial applicability

[0242] One embodiment of the present invention can be used in, for example, a communication system, a communication device (such as a mobile phone device, a base station device, a wireless LAN device, or a sensor device), an integrated circuit (such as a communication chip), or a program.

[0243] Description of Reference Numerals

[0244] 100 E-UTRA

[0245] 102 eNB

[0246] 104 EPC

[0247] 106 NR

[0248] 108 gNB

[0249] 110 5GC

[0250] 112, 114, 116, 118, 120, 124 interfaces

[0251] 122 UE

[0252] 200, 300 PHY

[0253] 202, 302 MAC

[0254] 204, 304 RLC

[0255] 206, 306 PDCP

[0256] 208, 308 RRC

[0257] 310 SDAP

[0258] 210, 312 NAS

[0259] 500, 604 Receiving Department

[0260] 502, 602 Processing Department

[0261] 504, 600 Sending Department

Claims

1. A terminal device communicating with a base station device, the terminal device comprising: a processing unit that, in processing an Ethernet Header Compression (EHC) protocol, appends an EHC context identifier to data; and a transmitting unit configured to transmit the data to which the EHC context identifier is attached to the base station apparatus, When the value of the EHC context identifier is a specific value, it indicates that Ethernet header compression is not applied to the Ethernet header of the data.

2. The terminal device according to claim 1, wherein The terminal device further comprises: a receiving unit configured to receive a radio resource control (RRC) message including an EHC setting from the base station apparatus, The processing unit sets an EHC protocol based on the EHC setting.

3. The terminal device according to claim 2, wherein: The EHC setting includes the maximum value of the EHC context identifier, The processing unit sets the EHC context identifier attached to the data to the specific value based on the absence of a context corresponding to the data among the stored EHC contexts when the number of stored EHC contexts reaches a maximum value of the EHC context identifier.

4. A communication method, comprising: In the process of Ethernet header compression EHC protocol, an EHC context identifier is attached to data; and the data attached with the EHC context identifier is sent to the base station device. When the value of the EHC context identifier is a specific value, it indicates that Ethernet header compression is not applied to the Ethernet header of the data.

5. A base station device for communicating with a terminal device, the base station device comprising: a receiving unit that receives data to which an Ethernet Header Compression (EHC) context identifier is attached from the terminal device during processing of the Ethernet Header Compression (EHC) protocol; and A processing unit that determines, if a value of the EHC context identifier is a specific value, that Ethernet header compression has not been applied to the Ethernet header of the data. The base station apparatus according to claim 5 , wherein: The base station device further comprises: a sending unit configured to send a radio resource control (RRC) message including an EHC setting to the terminal device, The EHC settings are used for setting the EHC protocol of the terminal device.

7. The base station apparatus according to claim 6, wherein: The EHC setting includes the maximum value of the EHC context identifier, When the number of stored EHC contexts reaches the maximum value of the EHC context identifier, the terminal device sets the EHC context identifier attached to the data to the specific value based on the fact that there is no EHC context corresponding to the Ethernet of the data in the stored EHC contexts.

Images