KR102683016B1 - Method and apparatus of performing unicast and multicast communication in new radio system supporting vehicle communication - Google Patents

Abstract

The present invention can provide a method for a terminal to perform communication using a V2X sidelink in a wireless communication system. At this time, the method for the terminal to perform communication may include a communication method for a specific service, obtaining source ID and destination ID information, and transmitting a message to another terminal based on the obtained source ID and destination ID. there is. At this time, the source ID and destination ID are determined based on the communication method for the specific service, and the message may include information indicating the communication method based on the specific service, the determined source ID information, and the determined destination ID information. Additionally, the present invention can provide a terminal that obtains and transmits communication method, source ID, and destination ID information for a specific service. At this time, the terminal can configure the information included in the message based on the communication method for the specific service.

Description

Method and device for performing unicast and multicast communication in a wireless communication system supporting vehicle communication {METHOD AND APPARATUS OF PERFORMING UNICAST AND MULTICAST COMMUNICATION IN NEW RADIO SYSTEM SUPPORTING VEHICLE COMMUNICATION}

The present invention relates to a method and device for performing unicast and multicast communication in a wireless communication system supporting vehicle to everything (V2X) communication. More specifically, it relates to a method and device for selectively performing sidelink communication in consideration of communication situations.

The International Telecommunication Union (ITU) is developing the International Mobile Telecommunication (IMT) framework and standards, and is currently discussing 5th generation (5G) communications through a program called “IMT for 2020 and beyond.” .

In order to meet the requirements presented by "IMT for 2020 and beyond", the 3rd Generation Partnership Project (3GPP) NR (New Radio) system takes into account various scenarios, service requirements, potential system compatibility, etc., and provides time-frequency Discussions are underway to support various numerologies for resource unit standards.

Additionally, V2X communication may refer to a communication method that exchanges or shares information such as traffic conditions while communicating with road infrastructure and other vehicles while driving. V2X refers to V2V (vehicle-to-vehicle), which refers to LTE/NR-based communication between vehicles; V2P (vehicle-to-pedestrian), which refers to LTE/NR-based communication between vehicles and terminals carried by individuals; and It may include vehicle-to-infrastructure/network (V2I/N), which refers to LTE/NR-based communication between roadside units/networks. At this time, a roadside unit (RSU) may be a transportation infrastructure entity implemented by a base station or a fixed terminal. As an example, it may be an entity that transmits speed notifications to a vehicle. In addition, based on the performance requirements to support V2X through the current 5G system, such as autonomous driving and vehicle remote control, we are discussing specific technologies additionally required for the LTE and NR systems, which are radio access technologies (RATs) within the 5G system. .

In the following, we propose a method of performing NR sidelink communication to support unicast and multicast between vehicles in the NR system.

The present invention can provide a method and device for a V2X terminal to perform unicast communication in a vehicle communication system.

The present invention can provide a method and device for a V2X terminal to perform multicast communication in a vehicle communication system.

The present invention can provide a method and device for supporting advanced V2X services by supporting unicast/multicast communication in a vehicle communication system.

The present invention can provide a method and device for configuring a message based on a communication method for a specific service in a vehicle communication system.

The present invention can provide a method for a terminal to perform communication using a V2X sidelink in a wireless communication system. At this time, the method for the terminal to perform communication may include a communication method for a specific service, obtaining source ID and destination ID information, and transmitting a message to another terminal based on the obtained source ID and destination ID. there is. At this time, the source ID and destination ID are determined based on the communication method for the specific service, and the message may include information indicating the communication method based on the specific service, the determined source ID information, and the determined destination ID information.

The features briefly summarized above with respect to the present disclosure are merely exemplary aspects of the detailed description of the present disclosure described below, and do not limit the scope of the present disclosure.

According to the present disclosure, a V2X terminal can perform unicast communication in a vehicle communication system. According to the present disclosure, a V2X terminal can perform multicast communication in a vehicle communication system.

According to the present disclosure, by supporting unicast/multicast communication in a vehicle communication system, it supports advanced V2X services and configures messages based on the communication method for a specific service to support V2X services that satisfy various service requirements. You can.

The present invention is not limited to the effects described above, and other effects not mentioned will be clearly understood by those skilled in the art from the description below.

1 is a diagram illustrating a wireless communication system to which the present disclosure can be applied.
Figure 2 is a diagram showing a V2X link to which this disclosure can be applied.
Figure 3 is a diagram for explaining a V2X scenario to which this disclosure can be applied.
Figure 4 is a diagram illustrating a scenario in which a V2X operation is performed using both a sidelink and communication with a base station to which the present disclosure can be applied.
5 is a D2D communication scenario to which this disclosure can be applied.
Figure 6 is a D2D communication scenario to which this disclosure can be applied.
FIG. 7 is a diagram illustrating an operation based on a base station scheduling mode and a UE autonomous decision mode to which the present disclosure can be applied.
Figure 8 may be a diagram showing the overall structure of V2X communication to which this disclosure can be applied.
Figure 9 is a diagram showing unicast transmission and broadcast transmission methods to which the present disclosure can be applied.
Figure 10 is a diagram showing a multicast transmission method to which the present disclosure can be applied.
FIG. 11 is a diagram illustrating a method for setting up a unicast and/or multicast link to which the present disclosure can be applied.
FIG. 12 is a diagram illustrating a method for setting up a unicast and/or multicast link to which the present disclosure can be applied.
FIG. 13 is a diagram illustrating a method for setting up a unicast and/or multicast link to which the present disclosure can be applied.
Figure 14 is a diagram showing the MAC PDU format when the terminal performs unicast/multicast communication.
Figure 15 is a diagram showing the SL-SCH format when the terminal performs unicast/multicast communication.
Figure 16 is a diagram showing subheaders for MAC SDU and padding when the terminal performs unicast/multicast communication.
Figure 17 is a diagram showing a method of updating the receiving terminal list.
Figure 18 is a flowchart showing a method of updating the receiving terminal list.
Figure 19 may be a diagram showing data flow.
Figure 20 is a diagram showing a method of transmitting a message based on the communication method for the service.
Figure 21 is a diagram showing the configuration of a base station device and a terminal device to which the present disclosure can be applied.

Hereinafter, with reference to the attached drawings, embodiments of the present disclosure will be described in detail so that those skilled in the art can easily practice them. However, the present disclosure may be implemented in many different forms and is not limited to the embodiments described herein.

In describing embodiments of the present disclosure, if it is determined that detailed descriptions of known configurations or functions may obscure the gist of the present disclosure, detailed descriptions thereof will be omitted. In addition, in the drawings, parts that are not related to the description of the present disclosure are omitted, and similar parts are given similar reference numerals.

In the present disclosure, when a component is said to be “connected,” “coupled,” or “connected” to another component, this is not only a direct connection relationship, but also an indirect connection relationship in which another component exists in between. It may also be included. In addition, when a component is said to “include” or “have” another component, this does not mean excluding the other component, but may further include another component, unless specifically stated to the contrary. .

In the present disclosure, terms such as first, second, etc. are used only for the purpose of distinguishing one component from other components, and do not limit the order or importance of components unless specifically mentioned. Accordingly, within the scope of the present disclosure, a first component in one embodiment may be referred to as a second component in another embodiment, and similarly, the second component in one embodiment may be referred to as a first component in another embodiment. It may also be called.

In the present disclosure, distinct components are intended to clearly explain each feature, and do not necessarily mean that the components are separated. That is, a plurality of components may be integrated to form one hardware or software unit, or one component may be distributed to form a plurality of hardware or software units. Accordingly, even if not specifically mentioned, such integrated or distributed embodiments are also included in the scope of the present disclosure.

In the present disclosure, components described in various embodiments do not necessarily mean essential components, and some may be optional components. Accordingly, embodiments consisting of a subset of the elements described in one embodiment are also included in the scope of the present disclosure. Additionally, embodiments that include other components in addition to the components described in the various embodiments are also included in the scope of the present disclosure.

In addition, this specification describes a wireless communication network, and work performed in the wireless communication network is performed in the process of controlling the network and transmitting data in a system (e.g., a base station) in charge of the wireless communication network, or in the process of controlling the network and transmitting data. Work can be performed on a terminal connected to the network.

That is, it is obvious that in a network comprised of a plurality of network nodes including a base station, various operations performed for communication with a terminal can be performed by the base station or other network nodes other than the base station. 'Base Station (BS)' can be replaced by terms such as fixed station, Node B, eNodeB (eNB), gNodeB (gNB), and Access Point (AP). In addition, 'terminal' can be replaced by terms such as UE (User Equipment), MS (Mobile Station), MSS (Mobile Subscriber Station), SS (Subscriber Station), and non-AP station (non-AP STA). You can.

In the present disclosure, transmitting or receiving a channel includes transmitting or receiving information or signals through the channel. For example, transmitting a control channel means transmitting control information or signals through the control channel. Similarly, transmitting a data channel means transmitting data information or signals through a data channel.

In the following description, the term NR system is used for the purpose of distinguishing the system to which various examples of the present disclosure are applied from existing systems, but the scope of the present disclosure is not limited by this term.

For example, the NR system supports various subcarrier spacing (SCS) in consideration of various scenarios, service requirements, and potential system compatibility. In addition, the NR system uses multiple channels to overcome unfavorable channel environments such as high path-loss, phase-noise, and frequency offset that occur at high carrier frequencies. Can support transmission of physical signals/channels through beams. Through this, the NR system can support services such as enhanced Mobile Broadband (eMBB), massive Machine Type Communications (mMTC)/ultra Machine Type Communications (uMTC), and Ultra Reliable and Low Latency Communications (URLLC). However, in this specification, the term NR system is used as an example of a wireless communication system, but the term NR system itself is not limited to the above-described features.

Additionally, as an example, 5G mobile communication technology may be defined. At this time, as an example, 5G mobile communication technology can be defined to include not only the above-described NR system, but also the existing Long Term Evolution-Advanced (LTE-A) system. In other words, 5G mobile communication may be a technology that operates by considering not only the newly defined NR system but also backward compatibility with previous systems.

For example, the sidelink field of 5G may include both sidelink technology in the LTE system and sidelink technology in the NR system. At this time, the sidelink field may be an essential field for improving performance through ultra-high reliability and ultra-low latency and incorporating new and diverse services.

1 is a diagram showing a wireless communication system to which the present invention is applied.

Figure 1 may be a network structure of Next Generation Radio Access Network (NG-RAN) or Evolved-Universal Mobile Telecommunications System (E-UMTS). The NG-RAN or E-UMTS system may include Long Term Evolution (LTE), advanced (LTE-A) systems, or a 5th generation mobile communication network, new radio (NR), etc.

Referring to FIG. 1, in the wireless communication system 10, a base station (BS) 11 and a user equipment (UE) 12 can transmit and receive data wirelessly. Additionally, the wireless communication system 10 may support device-to-device (D2D) communication. In the following, the above-described terminal may include both terminal devices used by general users, such as smartphones, and terminal devices mounted on vehicles.

Additionally, as an example, in the wireless communication system 10, the base station 11 may provide a communication service through a specific frequency band to a terminal existing within the coverage of the base station. Coverage served by a base station can also be expressed in terms of site. A site may include a number of areas 15a, 15b, and 15c, which may be referred to as sectors. Each sector included in the site can be identified based on a different identifier. Each sector 15a, 15b, and 15c may be a portion of the area covered by the base station 11.

In addition, as an example, the base station 11 generally refers to a station that communicates with the terminal 12, and includes eNodeB (evolved-NodeB), gNodeB, BTS (Base Transceiver System), Access Point, and Femto It may be called by other terms such as base station (Femto eNodeB), home base station (HeNodeB), relay, remote radio head (RRH), and distributed unit (DU).

The terminal 12 may be fixed or mobile, and may be a mobile station (MS), a mobile terminal (MT), a user terminal (UT), a subscriber station (SS), a wireless device, or a personal digital assistant (PDA). , wireless modem, handheld device, etc.

Additionally, the base station 11 may be called various terms such as megacell, macrocell, microcell, picocell, and femtocell, depending on the size of coverage provided by the base station. Cell may be used as a term to indicate all or part of the frequency band provided by the base station, the coverage of the base station, or the base station.

Hereinafter, downlink (DL: DownLink) refers to communication or a communication path from the base station 11 to the terminal 12, and uplink (UL: UpLink) refers to communication or communication path from the terminal 12 to the base station 11. It refers to the communication path. In the downlink, the transmitter may be part of the base station 11, and the receiver may be part of the terminal 12. In the uplink, the transmitter may be part of the terminal 12, and the receiver may be part of the base station 11.

Meanwhile, there are no restrictions on the multiple access technique applied to the wireless communication system 10. For example, Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single Carrier-FDMA (SC-FDMA), and OFDM-FDMA. , various multiple access techniques such as OFDM-TDMA and OFDM-CDMA can be used. Additionally, a Time Division Duplex (TDD) method transmitted using different times or a Frequency Division Duplex (FDD) method transmitted using different frequencies may be used for uplink transmission and downlink transmission.

At this time, as an example, Table 1 below may be a definition of each term in relation to the V2X described above.

[Table 1]

Additionally, as an example, abbreviations related to the components described below may be as shown in Table 2.

[Table 2]

Downlink (DL), uplink (UL), and sidelink (SL) communication may be possible in a communication system that supports V2X. As an example, Figure 2 is a diagram showing links considered in V2X. At this time, referring to FIG. 2, a communication system supporting V2X can only support the PC5 link, which is a link between the terminal (UE) and the terminal (UE) defined in D2D (ProSe). PC5 link refers to an interface defined between terminals and can be defined as a sidelink (SL) in the wireless access layer. Side link refers to a link in the wireless access layer for direct communication between vehicles for vehicle communication, but is not limited to the above.

Additionally, Figure 3 may be a V2X operation scenario using communication with a terminal (or vehicle) and a base station. As an example, referring to FIG. 3, a communication system supporting V2X may support only the Uu link, which is a link between a base station and a terminal (UE), or between a wireless access network and a terminal (UE). The Uu link may include an uplink (UL), a path through which a terminal transmits a signal to a base station, and a downlink (DL), a path through which a base station transmits a signal to the terminal.

Additionally, as an example, necessary terms related to V2X may be defined as shown in Tables 1 and 2 above. At this time, as an example, D2D (Device to Device) may mean communication between devices. Additionally, ProSe may refer to a proximity service for a terminal performing D2D communication. Additionally, SL (sidelink) may refer to the above-described sidelink, and SCI (Sidelink Control Information) may refer to control information related to the above-described sidelink. Additionally, PSSCH (Physical Sidelink Shared Channel) may be a channel through which data is transmitted through a sidelink, and PSCCH (Physical Sidelink Control Channel) may be a channel through which control information is transmitted through a sidelink. Additionally, PSBCH (Physical Sidelink Broadcast Channel) is a channel that transmits signals in a broadcast manner through a sidelink, and system information can be transmitted. Additionally, PSDCH (Physical Sidelink Discovery Channel) is a discovery channel and may be a channel used for signal discovery.

Additionally, V2V can mean communication between vehicles, V2P can mean communication between vehicles and pedestrians, and V2I/N can mean communication between vehicles and infrastructure/networks. This will be described later.

At this time, as an example, in relation to V2X, the terminal described below may be a vehicle. In the following, for convenience of explanation, it is collectively referred to as a terminal, but the terminal may be a vehicle for V2X. Additionally, as an example, a terminal may refer to a device capable of performing communication with a sidelink and a base station, and is not limited to the above-described embodiment. However, in the following, it is referred to as a terminal for convenience of explanation.

Additionally, Figure 4 may be a scenario in which a V2X operation is performed using both the above-described sidelink and communication with the base station.

Referring to FIGS. 4A and 4B, both the PC5 link and the Uu link described above including a Road Side Unit (RSU) in the form of a terminal (UE) may be considered. Figure 4a shows a case where a base station transmits a downlink signal to multiple vehicles, and Figure 4b shows a case where a terminal (UE, RSU) transmits a sidelink signal to multiple vehicles.

As an example, D2D communication may refer to communication that directly transmits and receives data between terminals. In the following, it is assumed that the terminal (or vehicle) supports D2D communication. Additionally, D2D communication can be replaced by the expression Proximity based Service (ProSe) or ProSe-D2D communication. The use of the term ProSe for D2D communication does not mean that the meaning of directly transmitting and receiving data between terminals is changed, but that the meaning of proximity-based service can be added.

D2D communication involves a discovery procedure for communication between terminals in-coverage or out-of-coverage, and direct communication (transmitting and receiving control data and/or traffic data between terminals) It can be divided into direct communication procedures. At this time, as an example, a terminal that transmits a signal based on D2D communication may be a transmitting terminal (Tx UE). Additionally, a terminal that receives a signal based on D2D communication may be a receiving terminal (Rx UE). At this time, the transmitting terminal can transmit a discovery signal, and the receiving terminal can receive the discovery signal. The roles of the transmitting terminal and the receiving terminal may change. A signal transmitted by a transmitting terminal may be received by two or more receiving terminals.

The above-described D2D communication can be used for various purposes. As an example, D2D communication within network coverage based on commercial frequencies can be used for at least one of public safety, transportation network services, ultra-low latency services, and commercial purposes. , but is not limited to the above-described embodiments. Additionally, as an example, if it is based on a frequency dedicated to the transportation network, D2D communication through that frequency can be used only for transportation network communication and transportation safety, etc., regardless of network coverage.

In a cellular system, when terminals in close proximity perform D2D communication, the load on the base station can be distributed. Additionally, when terminals that are close to each other perform D2D communication, the terminals transmit data over a relatively short distance, so the consumption of the terminal's transmission power and transmission latency can be reduced. Additionally, as an example, from the overall system perspective, because existing cellular-based communication and D2D communication use the same resources, frequency use efficiency can be improved when they do not overlap spatially.

D2D communication (or V2X communication) can be divided into network coverage (base station coverage) in-coverage (IC) communication and network coverage out-of-coverage (OCC) communication. At this time, IC may be communication between terminals located within network coverage. Additionally, OCC may be communication between terminals located outside of network coverage.

As another example, D2D communication (or V2X communication) can be divided into communication between a terminal located within network coverage and a terminal located outside of network coverage.

As an example, Figure 5 may be a scenario for D2D communication (or V2X communication). At this time, referring to FIG. 5, the first terminal (V2X UE1, 510) and the second terminal (V2X UE2, 520) may be able to communicate with the base station because they are located within the network coverage. That is, the first terminal 510 and the second terminal 520 can transmit and receive data for vehicle communication services through a base station (Uu interface). That is, the first terminal 510 and the second terminal 520 can exchange data for vehicle communication services with each other through UL data transmission and DL data reception. On the other hand, as an example, a third terminal (V2X UE3, 530) and a fourth terminal (V2X UE4, 540) may be located outside the network coverage. At this time, if the third terminal 530 and the fourth terminal 540 are in a position where inter-terminal communication with the first terminal 510 and the second terminal 520 is not possible, the third terminal 530 and the fourth terminal 540 cannot exchange data for vehicle communication service with the first terminal 510 and the second terminal. In other words, a terminal located in a location where physical signals cannot reach may not be able to communicate with other terminals, base stations, servers, etc.

As an example, a case where the fourth terminal 540 outside the network coverage needs to connect to the network for reasons such as vehicle communication service or commercial service may be considered. At this time, when D2D communication is possible with an RSU (Road Side Unit, 560) existing within the network service range through D2D communication, the RSU performs a relay role and the fourth terminal 540 outside the network coverage communicates with the base station through an indirect path. Data can be sent and received. At this time, as an example, the RSU 560 may be a UE type. However, the RSU 560 may be of another type and is not limited to the above-described embodiment. That is, the RSU 560 performs a relay role so that the fourth terminal 540 can transmit vehicle communication service data to the RSU 560 through the side link (SL). The RSU 560 may transmit the vehicle communication service data to the base station 550 using uplink (UL) transmission through the Uu interface. Afterwards, the first terminal 510 and the second terminal 520 can receive vehicle communication service data of the fourth terminal 540 from the base station 550. That is, a terminal located outside the network coverage can transmit data to terminals within the network coverage through a relay terminal such as an RSU and the base station of the relay terminal.

As another example, Figure 6 is a diagram showing a D2D communication scenario. At this time, referring to FIG. 6, the fourth terminal (V2X UE4, 640) may transmit data to the RSU (660) as described above. At this time, as an example, the data may be vehicle communication service data as described above. In the case described above, the third terminal (V2X UE3, 630) exists in a location where communication with the fourth terminal 640 is not possible, but may be a terminal capable of sidelink communication with the RSU (660). At this time, the third terminal 630 also needs to check the data of the fourth terminal 640. More specifically, because the V2X service is sensitive to delay time, the RSU 660 is used to transmit data received from the fourth terminal 660 to the base station 650 through the Uu interface (LTE or NR uplink). In addition to preparation, there is a need to make arrangements for passing data through sidelinks. That is, in order to reduce the delay time that occurs while the RSU 660 transmits data to the base station 650 and transmits the data back to the RSU 660, data transmission can be performed through sidelink communication. As an example, the RSU 660 may operate in a mode controlled by a base station or in a terminal autonomous decision mode, which will be described later. At this time, when the RSU 660 operates in a mode controlled by the base station, the data received from the fourth terminal 640 is determined to be data to be included in BSR (Buffer Status Reporting) for transmission through LTE or NR, and at the same time, the side It may be determined as data to be included in the link (SL) BSR. In other words, the vehicle communication service data received from the above-described fourth terminal 640 is delivered to the PDCP/RLC layer in the RB (radio bearer) on the LTE side, and the same information is also delivered to the PDCP/RLC layer in the RB on the sidelink side. You can.

At this time, PPPP (ProSe Priority per Packet) of data delivered to the RB on the sidelink side can maintain the priority of the received packet. For example, if there is no sidelink-side RB mapped to the priority of the received packet, the RSU 660 may configure a new RB supporting the priority and transmit the packet, and is limited to the above-described embodiment. It doesn't work.

In addition, although referred to as D2D communication in the above, this may be V2X communication, and the above-described content can be equally applied. However, in the above description, it is referred to as D2D communication for convenience of explanation, and is not limited to the above description.

As an example, in the present disclosure, an operation mode may be defined according to a resource allocation method for control information and data transmission for V2X communication or direct link (e.g. D2D, ProSe, or SL) communication.

As an example, eNodeB resource scheduling mode (mode 3) is a system in which a base station or relay node schedules resources used by the terminal to transmit V2X (or direct link) control information and/or data. It could be a mode. Through this, the terminal can transmit V2X (or direct link) control information and/or data, and this mode may be the base station resource scheduling mode described above.

As an example, (a) of FIG. 7 may represent a base station scheduling mode.

Referring to (a) of FIG. 7, the base station 710 provides scheduling information about resources to be used for data transmission through downlink control information (DCI) to the sidelink (or direct link) transmission terminal (UE A). , 720). Accordingly, the sidelink (or direct link) transmitting terminal 720 may transmit sidelink (or direct link) control information (SCI) and data to the sidelink (or direct link) receiving terminal (UE B, 730). . Meanwhile, the sidelink (or direct link) receiving terminal (UE B, 730) may receive sidelink (or direct link) data based on sidelink (or direct link) control information (SCI), and perform the above-described implementation. It is not limited to examples.

In addition, referring to (b) of FIG. 7, in the UE autonomous resource selection mode (Mode 4), the terminal independently selects the resources used by the terminal to transmit control information and data, and these resources The selection may be determined by the terminal sensing in a resource pool (i.e., a set of resource candidates). Through this, the terminal can transmit control information and data, and this mode may be a terminal autonomous resource selection mode.

As an example, the sidelink (or direct link) transmitting terminal (UE A, 740) provides sidelink (or direct link) control information and Data can be transmitted. At this time, the sidelink (or direct link) receiving terminal 750 may receive sidelink (or direct link) data based on sidelink (or direct link) control information.

At this time, as an example, the above-described base station resource scheduling mode may be referred to as Mode 1 in sidelink (or direct link) communication for D2D, etc. Additionally, the above-described base station resource scheduling mode may be referred to as Mode 3 in sidelink communication for V2X, etc. Additionally, the terminal autonomous resource selection mode may be referred to as Mode 2 in sidelink (or direct link) communication for D2D, etc. Additionally, the terminal autonomous resource selection mode may be referred to as Mode 4 in sidelink communication for V2X, etc. However, this is only one example and is not limited to the above-mentioned names. In other words, the same object and the same operation can be viewed in the same mode.

In addition, for convenience of explanation, the following description is based on V2X communication, but is not limited thereto. For example, the present invention can be equally applied to direct link-based communication such as D2D, ProSe, etc., and is not limited to the above-described embodiment.

Additionally, as an example, the terminal may be considered to be within the reception range of the carrier used for V2X side link communication whenever it detects a cell of the corresponding carrier according to a specific criterion. At this time, if the terminal authorized for V2X sidelink communication is within coverage at the frequency used for V2X sidelink communication, or the base station provides V2X sidelink configuration for that frequency (including when the terminal is out of coverage at that frequency) , the terminal uses the above-described scheduled resource allocation or terminal autonomous resource selection depending on the base station configuration. If the terminal is outside the coverage of the frequency used for V2X side link communication and the base station does not provide V2X side link configuration for that frequency, the terminal can use a full set of transmission and reception resources preconfigured in the terminal. That is, it may be based on the terminal autonomous decision mode.

At this time, as an example, in the base station scheduling mode, the terminal may request transmission resources from the base station to transmit data, as described above. At this time, as an example, the base station transmits V2X-specific configuration information as shown in Table 3 to the terminal, and for this purpose, a signaling procedure (e.g. RRC connection reconfiguration message) in the Radio Resource Control (RRC) layer is used. can be used

[Table 3]

Additionally, as an example, the terminal autonomous decision mode (mode 4) can be considered. At this time, the detailed configuration information for the transmission resource pool in mode 4 may be configured the same as Table 3 above, which is the detailed configuration information for the transmission resource pool for mode 3. At this time, in mode 4, a plurality of transmission resource pool information may be provided in the form of a list (SL-CommTxPoolListV2X). In addition, if necessary, the base station may configure a new transmission resource pool capable of operating in mode 4 or transmit an RRC connection reconfiguration message to release some of the existing transmission resource pools, and is not limited to the above-described embodiment. In addition, the terminal can independently select some of the resources to be used for actual V2X data transmission among the resources in the transmission resource pool, and the base station may transmit reference parameter information that serves as a basis for the terminal to make this selection to the terminal.

For example, in mode 4, the base station may provide information as shown in Table 3 above to the terminal through an RRC connection reconfiguration message, similar to mode 3.

As another example, in mode 4, a terminal in RRC IDLE mode can receive a system information block (referred to as V2X service-related system information) containing information related to vehicle communication services from the base station. At this time, the terminal may configure its own transmission resource pool based on the received system block information.

Additionally, as an example, the concept of a zone can be used when a terminal selects resources on its own. Zones may be configured or pre-configured by a base station. Once a zone is configured (or pre-configured), it can be divided into geographic areas using a single fixed reference point (i.e. geographic coordinates (0, 0)), length and width. and the divided area can be defined as a zone. The terminal can determine the zone ID using the length and width of each zone, the number of zones, a single fixed reference point, and the geographic coordinates of the terminal's current location. At this time, zones can be configured both inside and outside network coverage. When the terminal is within network coverage, the length and width of each zone and the number of zones may be provided to the terminal by the base station. On the other hand, if the terminal is out of network coverage, the terminal can use pre-configured zone information.

Based on the mapping relationship between transmission resources and zones, the terminal can select the V2X sidelink resource pool for the zone in which the terminal is located. Afterwards, the terminal can select a sidelink resource by performing sensing based on the selected resource pool. Sensing is a resource selection mechanism, and the terminal selects/reselects some specific sidelink resources and reserves transmission resources based on the sensing results. Up to two transmission resource reservation processes are allowed for the terminal, and at this time, the transmission resource reservation processes are performed in parallel. However, at this time, the terminal can only select a single resource for V2X sidelink transmission.

Figure 8 may be a diagram showing the overall structure of V2X communication. At this time, as an example, referring to FIG. 8, V2X terminals 820 and 830 may be composed of a V2X application and a communication protocol stack. At this time, communication between V2X terminals 820 and 830 may be possible through a PC5 link. Additionally, communication between V2X applications may be possible through a V5 link.

Additionally, communication between the base station 810 and the terminals 820 and 830 may be possible through a Uu link. Meanwhile, when the terminal 820 transmits a V2X message through the PC5 interface, the terminal 820 can perform transmission according to settings in the application layer. That is, the application layer of the terminal can set priority information, QoS information, etc. for the generated V2X message and then transmit the above-described information along with the V2X message to the AS (Access Stratum) layer. At this time, the AS layer that received the above-described configuration information and V2X message can check the priority and reliability of the V2X message and map the V2X message to an appropriate SLRB (Sidelink Radio Bearer). At this time, the PDCP, RLC, MAC, and PHY layers of the terminal receive the V2X message through the AS layer, prepare to transmit the message, and perform transmission.

As described above, V2X communication may be accomplished through a base station, or may be accomplished through direct communication between terminals. At this time, when passing through a base station, in LTE-based V2X communication, transmission and/or reception may be performed through the Uu link, which is a communication interface between the LTE base station and the terminal. Additionally, when using a sidelink as direct communication between terminals, in LTE-based V2X communication, transmission and/or reception can be performed through the PC5 link, which is a communication interface between LTE terminals.

For example, the sidelink field of 5G may include both sidelink technology in the LTE system and sidelink technology in the NR system. At this time, the sidelink field may be an essential field for improving performance through ultra-high reliability and ultra-low latency and incorporating new and diverse services.

In the following, for convenience of explanation, operations and related information for V2X are described based on the NR system. However, the following features may not be limited to a specific system, and may be equally applied to other systems, and are not limited to the above-described embodiments. As an example, the following description can also be applied to operations for LTE V2X, and is not limited to the above-described embodiment.

Meanwhile, V2X may be vehicle-based communication. At this time, the concept of a vehicle is changing from a simple means of transportation to a new platform. For example, IT technologies are being incorporated into vehicles, and various V2X services are being provided based on this. For example, services such as traffic accident prevention, traffic environment improvement, autonomous driving, and remote driving are being provided. To this end, in relation to V2X, the need for development and application of sidelink-related technologies is increasing.

More specifically, with respect to existing communication technology, communication from a base station to a terminal may be downlink, and communication from a terminal to a base station may be uplink. However, communication between the terminals as well as communication between the base station and the terminal may be necessary, and communication from the terminal to the terminal may be the side link described above. As an example, in relation to the above-mentioned V2X, communication between vehicles or between vehicles and other objects (objects other than a base station, such as a pedestrian UE or a UE-type roadside unit (RSU)) This could be a side link. In other words, when performing vehicle-based communication, there are limits to communication with a base station alone, so the above-described side link technology can be developed and applied.

Additionally, as an example, a vehicle may be referred to as a terminal, and hereinafter, for convenience of explanation, it will be referred to as a terminal. However, it is not limited to this, and may be the above-described vehicle, and is not limited to the above-described embodiment.

Additionally, as an example, there may be a difference in the communication method between the base station and the terminal in the NR system (uplink/downlink) and the communication method between the base station and the terminal in the existing system (uplink/downlink). That is, some features may be similar, and there may be changes based on the NR system, which is a new system. Additionally, as an example, there may be a difference between the sidelink in the existing system (e.g. LTE) and the sidelink in the NR system.

For example, in NR V2X, in addition to the services supported by LTE V2X, services such as platooning, remote driving, high-altitude driving, and sensor expansion can be provided. At this time, the above-mentioned services are services that require low latency and high reliability, and an improved NR system and a new NR sidelink may be needed to meet these strict requirements.

For example, NR V2X may require support for terminal-to-device and unicast communication to support platooning, sensor expansion, high-altitude driving, and remote driving services. Additionally, support for multicast communication, in which one terminal communicates with multiple terminals, may be required. Below, based on the above, a description of unicast/multicast and NR V2X scenarios requiring unicast/multicast communication are described.

Referring to FIG. 9, unicast transmission, multicast transmission, and broadcast transmission can be performed. At this time, as an example, referring to FIG. 9, unicast transmission may mean that one terminal 910 transmits a message to another terminal 920. In other words, it may mean one-to-one transmission. Additionally, broadcast transmission may be a method of transmitting a message to all terminals regardless of whether the receiving terminal supports the service. That is, in FIG. 9, one terminal 930 can transmit a message regardless of whether the receiving terminals 940, 950, and 960 support the service. Meanwhile, the multicast transmission method may be a method of sending a message to multiple terminals belonging to a group.

At this time, referring to FIG. 10, the terminal 1010 included in group A may transmit a message to the receiving terminals 1020 and 1030 included in group A through a multicast method. At this time, the message is not transmitted to receiving terminals included in group B, which is different from the broadcast method. Additionally, as an example, the terminal 1030 included in group B may also transmit a message to the receiving terminals 1040 and 1050 included in group B through a multicast method, as described above. Meanwhile, as an example, unicast and multicast transmission methods can be applied to V2X communication, and this is described in detail below.

Regarding V2X services, platooning can be considered as a new service. At this time, information exchange within the platoon may be necessary based on platoon driving. In the case of platoon driving, there may be a leader in the platoon. At this time, the swarm leader needs to report surrounding traffic data to group members in real time. Group members also need to exchange information in real time within the group. As an example, a case where vehicles A, B, C, and D form a cluster may be considered. At this time, vehicle A may be the leader of the group. For example, group members share surrounding real-time traffic and road information, and vehicle A can report all information to the RSU (Road Side Unit).

At this time, if vehicle A discovers through RSU that there is road congestion due to a traffic accident ahead of the road, vehicle A can share the information received from RSU with group members (B, C, D). As an example, vehicles B, C, and D that have received the above-described information as vehicles (or terminals) in the group can perform updates on driving. For example, you can update driving maps in real time, reduce speed, change routes, etc.

Additionally, as an example, advanced driving may be considered as a V2X service. At this time, control information for high-altitude driving may be exchanged. For example, Cooperative collision avoidance (CoCA) of connected automated vehicles, the vehicle's CAM, DENM safety messages, data from sensors, in addition to the action list such as braking and acceleration commands, can better assess and adjust the probability of an accident. Control information can be exchanged between vehicles to enable this. At this time, the above-described information can be used in the application to adjust road traffic flow through 3GPP V2X communication.

For example, assuming that terminals (or vehicles) A, B, and C perform CoCA, terminal A detects danger through the application and sends CoCA-related messages (trajectory, sensor data, brake command, etc.) through V2X communication. can be exchanged. By receiving the above-mentioned message, terminals B and C can check the CoCA information of terminal A to adjust the speed and change the location. In order to support the above-described operations, there is a need to enable message exchange between devices in V2X communication. Additionally, the above-mentioned information must be able to support a data throughput of 10 Mbps. Additionally, the network can enable terminals to exchange messages with 99.99% reliability. In other words, smooth data processing and high reliability may be required. At this time, for example, when information for high-altitude driving is shared between terminals, cooperative recognition to share detected objects between vehicles within the same area and cooperative actions to share approximate driving intentions such as changing lanes are necessary. You can.

More specifically, local collaborative awareness can be generally defined as sharing local awareness data (abstracted data and/or high-resolution sensor data) using V2X communications to extend the capabilities of onboard sensors for sensing. At this time, each vehicle and/or RSU may share its perception data obtained from its local sensors (eg, camera, LIDAR, radar, etc.) with nearby vehicles.

Additionally, cooperative behavior can be basically defined as vehicles in close proximity sharing their driving intentions.

As an example, each vehicle may share detected objects (eg, abstract object information detected by a sensor) and/or driving intentions with other vehicles. Through this, each vehicle can obtain information about surrounding objects that cannot be obtained only from local sensors and obtain the driving intentions of other nearby vehicles. In this case, road safety and traffic efficiency can be improved.

This operation requires low delay and high reliability, and therefore, NR V2X must be able to send and receive messages between terminals directly or through RSU. At this time, a broadcast method, a multicast method, or periodic information exchange may be used. In addition, cooperative automatic driving can be supplemented through “Emergency Trajectory Alignment (EtrA)” messages between terminals, taking risk situations into account. Movement cooperation through EtrA can help drivers drive safely in dangerous situations. That is, the EtrA message may contain sensor data and state information with specific information for cooperative avoidance coordination for safe security against unexpected road conditions.

For example, when a vehicle obtains information about obstacles on the road through a sensor, the vehicle may calculate actions to avoid an accident based on the information. Additionally, the vehicle can inform other vehicles of this information through V2X communication.

To support this operation, V2X may need to enable communication between terminals with [3] ms end-to-end delay and [99.999] % reliability and low data rate [30] Mbps within a communication range of [500] m. .

Additionally, as an example, a lane change scenario based on cooperation between terminals can be considered. When a vehicle wants to change lanes on a multi-lane road, information exchange between vehicles may be necessary to ensure safe and efficient lane change.

As an example, a case may be considered where vehicles A, B, and C support V2X communication, and vehicles B and C are located in a lane adjacent to A. At this time, vehicle A may want to change lanes to an adjacent lane between vehicles B and C. Vehicle A can notify vehicles B and C to change lanes and request creation of a gap. Vehicles B and C that received the above message can confirm that they will create a gap according to the request and inform vehicle A of this fact. Vehicle A, which receives the message, can move the lane. These operations can be supported through message exchange between terminals.

Extended Sensor can be considered as another V2X service. At this time, as an example, sensor and video information may be shared between terminals (or vehicles). For example, a driver's visual range can be impaired in some road traffic situations, such as when a truck is driving in front. Video data transmitted from one vehicle to another can assist drivers in these safety-critical situations. Additionally, video data may be collected and transmitted via a capable UE-type RSU.

Extended sensors enable inter-vehicle exchange of raw or processed data collected via local sensors or live video data between vehicles, RSUs, pedestrian units and V2X application servers. This allows vehicles to have improved environmental awareness beyond what their own sensors can detect and provides a more holistic view of the local situation.

However, sharing preprocessed data where objects extracted by automatic object detection are located may not be sufficient. For example, sharing high-resolution video data may allow drivers to drive according to their safety preferences, but sharing low-resolution video data may not be sufficient for driving because obstacles may not be visible and may be overlooked.

Therefore, these operations require low latency and high reliability. Additionally, an operation is required to enable communication between terminals within a communication range of [100] m, at a data rate of [10] Mbps, with a latency of [50] ms, and with [90]% reliability.

In order to support V2X services as described above, low latency and high reliability may be required.

At this time, when sharing information based on the above-mentioned broadcast, it may be difficult to meet the requirements required by V2X. Therefore, in NR V2X, in addition to the broadcast mechanism as described above, there is a need to support a new two-way transmission mechanism, unicast and/or multicast, to handle high-speed data transmission between vehicles.

Considering the above, the following describes a method for supporting unicast and/or multicast for V2X in the NR system. Meanwhile, the following may be an example of a case where V2X terminals perform communication based on a V2X sidelink. However, it is not limited to the above, and may be expanded in similarly applicable fields.

Based on the above, in the V2X of the existing system (e.g. LTE), sidelink data transmission and reception could be performed using the broadcast communication method. However, the V2X of the new system (e.g. NR) can support unicast/multicast as well as broadcast. Additionally, definition of terminal operation to support the above-described unicast/multicast communication may be necessary, and this is described below.

Based on the above, the V2X terminal can perform unicast and/or multicast operations to support V2X services. At this time, as an example, Figure 11 may be a method for setting up a unicast and/or multicast link.

As an example, a terminal (or vehicle, hereinafter referred to as a terminal) may wish to share information with surrounding terminals about a specific QoS. At this time, the terminal can find a terminal that supports the corresponding service and trigger the service. (S1110) That is, the terminal can perform unicast/multicast operations with a terminal that supports the corresponding service. At this time, the above-described operation may be performed in the application layer of the terminal.

As described above, the application layer can exchange information with other applications through the V5 link and find applications that support the same service. After (1120), the application layer of the terminal may start the link setup process for unicast or multicast communication. At this time, when the application layer sets up a unicast and/or multicast link, the configuration shown in Table 4 below can be considered. That is, the application layer can consider the number of terminals supporting the service and the requirements for the service.

More specifically, in the case of unicast, it can be one-to-one communication, and since a direct connection is established between terminals, information on each terminal can be efficiently identified and data transmission and reception can be performed considering the situation of each terminal. As an example, there may be many cases in which requirements for a service can be satisfied. On the other hand, since it is one-to-one communication, if the number of terminals supporting the service is large, multiple links must be formed, which may require a lot of resource settings. Therefore, the number of terminals that can perform communication simultaneously may be limited. On the other hand, multicast is a method that can transmit to multiple terminals at the same time, allowing efficient use of resources. However, compared to the unicast method, it may be difficult to perform transmission and reception by considering the characteristics and circumstances of each terminal. Therefore, the application layer can determine the communication method by considering the number of terminals supporting the following services and service requirements.

[Table 4]

For example, if many terminals want to participate in the service, the terminals can use the multicast method. As another example, if the number of terminals supporting the service is not large and the service requirements are sensitive to delay and require high reliability, the unicast method can be used.

Considering the above two matters, the application layer can determine which communication method to use (1130). Thereafter, the application layer may assign an ID to be used by the terminal during unicast and/or multicast communication (1140). Afterwards, the terminal can perform data transfer (1150) based on the assigned ID.

At this time, as an example, the above-mentioned IDs may be “Source Layer-2 ID” and “Destination Layer-2” ID. “Source Layer-2 ID” may be an ID to identify the sender of data, and may be delivered within the MAC header. In other words, “Source Layer-2 ID” may be the ID for the terminal. Additionally, “Destination Layer-2 ID” may be an ID to identify the destination of data, and the above-mentioned ID may also be transmitted within the MAC header. At this time, for example, in the case of unicast, “Destination Layer-2 ID” can be set considering the service and the counterpart terminal (or target terminal). Additionally, as an example, in the case of multicast, “Destination Layer-2 ID” can be set in consideration of the service. That is, ID information that distinguishes the data sender and ID information that distinguishes the service and data receiver may be included in the MAC header.

As another example, the above-mentioned IDs may be “Source Layer-1 ID” and “Destination Layer-1 ID”. “Source Layer-1 ID” is an ID to identify the sender of data and can be used to identify terminals in the PHY layer. In other words, “Source Layer-1 ID” may be the ID for the terminal. Additionally, “Destination Layer-1 ID” is an ID to identify the destination of data, and the above-mentioned ID can also be used in the PHY layer. At this time, for example, in the case of unicast, “Destination Layer-1 ID” can be set considering the service and the counterpart terminal (or target terminal). Additionally, as an example, in the case of multicast, “Destination Layer-1 ID” can be set in consideration of the service. That is, ID information that distinguishes the data sender and ID information that distinguishes the service and data receiver may be included in the MAC header. That is, ID information that distinguishes the data sender and ID information that distinguishes the data receiver can be set in the PHY layer.

As another example, both ‘Source Layer-2 ID’ and ‘Source Layer-1 ID’ may be used. Additionally, both ‘Destination Layer-2 ID’ and ‘Destination Layer-1 ID’ can be used similarly.

More specifically, when transmission is performed in a unicast manner based on information received from the application layer of the terminal, the terminal can further obtain source ID information that can be used in unicast communication from the application layer. there is. In addition, information about the destination ID can be further obtained from the application layer by considering the source ID and the corresponding service that wants to share information through unicast. At this time, as an example, the destination ID may be the same for both terminals performing unicast communication. For example, when terminal A and terminal B perform unicast communication for a specific service, terminal A and B may have respective terminal IDs (e.g. Source ID). Additionally, the destination ID can be set considering the source ID and service characteristics of each terminal. At this time, the destination ID may be common to terminals A and B.

As another example, when transmission is performed in a multicast manner based on information received from the application layer of the terminal, the terminal receives a destination ID for the service from the application layer and a terminal to use in multicast communication for the service. Source ID information, which is ID, can be received. For example, when terminals A, B, C, and D perform multicast communication, terminals A, B, C, and D may each have a terminal ID (e.g. Source ID). Additionally, the destination ID can be set as the ID for a service for which information is to be shared through multicast communication. At this time, the destination ID may be common to all terminals supporting the service, that is, A, B, C, and D.

When ID setting is completed based on the above, the application layer of the terminal can support unicast/multicast communication through unicast link setting or multicast group setting.

For example, to support unicast communication between terminals, the application layer of the terminal may start a link establishment process. The link establishment process is used to establish a safe direct connection between two terminals. In the link establishment process, there may be a terminal requesting link establishment and a target terminal responding to it.

At this time, before starting the link establishment process, the terminal first needs to satisfy some conditions in order to establish a link. The above-mentioned condition may be a case where there is no link existing between the requesting terminal and the target terminal, the ID for the requesting terminal is available, and the ID for the target terminal is available.

At this time, if the above-mentioned conditions are satisfied, the terminal requesting link establishment can start the link establishment process by generating a “DIRECT_COMMUNICATION_REQUEST” message. The above-described message may include at least one of terminal information, IP address information, and security information. At this time, the terminal that created the “DIRECT_COMMUNICATION_REQUEST” message based on the above-described information can transmit the message along with the source ID and destination ID to the lower layer to deliver the above-mentioned message. there is. Additionally, a predetermined timer can be started at the time of transmission. While the above-described timer is running, the requesting terminal can expect a response message from the target terminal.

At this time, as an example, the target terminal that has received the link establishment request message can check the information included in the message. Afterwards, the target terminal can decide whether to accept the request.

For example, based on the IP address information in the above-described message, the target terminal can check whether at least one common IP address exists. At this time, if at least one common IP address exists, the target terminal can verify security with the requesting terminal, and when it determines that security has been successfully achieved, it can transmit an authorization message for the link establishment request.

At this time, the link establishment permission message may be “DIRECT_COMMUNICATION_ACCEPT”, and the above-mentioned message may include IP address information. At this time, the requesting terminal that has received the ACCEPT message can stop the running timer and successfully complete the link establishment process with the target terminal.

On the other hand, if the target terminal rejects the link establishment request, the target terminal may transmit a “DIRECT_COMMUNICATION_REJECT” message. At this time, the message may include a reason for rejection. The requesting terminal receiving the REJECT message may stop attempting to establish a link with the target terminal.

As another example, to support multicast communication, the application layer of the terminal may start a group configuration process. A group can be set for a specific QoS, and the group can include terminals that support services for QoS as group members. When setting a group, the group can be set through the application server. At this time, the application server can complete group setting by notifying the application of each group member of the set group.

The application layer of the terminal that has completed the above-described ID setting and link or group setting can inform the lower layers (MAC, PHY) of the terminal of the above-described IDs and communication method to apply the method selected by the terminal. Additionally, in order to share information about the service to be communicated through unicast/multicast, data for the service can be transmitted to the lower layer of the terminal (1150).

The lower layer of the terminal can send and receive messages based on information received from the application layer. At this time, the following describes how the terminal transmits and receives messages in unicast/multicast communication based on “Source Layer-2 ID” and “Destination Layer-2 ID”, which will be described later.

Additionally, as an example, FIG. 12 is a diagram showing a method of transmitting a message based on unicast and/or multicast based on the above.

As described above, information about the communication method determined in the application layer can be received (S1210). At this time, the terminal can assign an ID based on the information about the determined communication method. In other words, the terminal can assign an ID that can be used in unicast or multicast communication. (S1220) At this time, the terminal forms a link with the target terminal (or target terminals) based on the determined communication method and uses unicast or multicast communication. Multicast communication can be performed, as described above. (S1230)

Additionally, as an example, unicast and multicast links may be set to overlap. As an example, Figure 13 is a diagram showing unicast and multicast link settings.

At this time, in V2X communication, the surrounding environment of the terminal may continuously change depending on the driving path, speed, etc. Therefore, nearby terminals that support the service may also continue to change. More specifically, when the terminal starts sharing information about a specific service, the terminal can search for a terminal that supports the specific service. At this time, if there is only one terminal supporting a specific service, the terminal may be instructed to perform a unicast operation. However, as an example, when the location of the terminal changes, multiple terminals may support a specific service at the time the location of the terminal changes.

At this time, the terminal may need to perform multicast communication considering resource efficiency, terminal capabilities, etc. In other words, even if the terminal initially operates in unicast for a specific service, there is a need to operate in multicast at a specific point in time. Likewise, even if the terminal initially operates in multicast for a specific service, there is a need to operate in unicast at a certain point.

For example, when a terminal communicates with multiple terminals for the same service using a unicast method, the terminal must transmit the same message to each terminal individually. At this time, if the number of receiving terminals is large, this transmission operation may cause a load on the terminal and may be inefficient in terms of resource use.

Therefore, if there are many unicast communication terminals for a specific service, the terminal can switch to the multicast method. At this time, as an example, when there are many communication terminals, it may mean when there are more communication terminals than the preset number.

At this time, as an example, the preset number of switches from unicast method to multicast method may be signaled by the base station. As another example, the preset number may be determined by the terminal in consideration of terminal capabilities and terminal conditions, and is not limited to the above-described embodiment.

Additionally, as an example, the multicast method may be efficient in resource use, but may not be able to perform transmission considering the environment for individual terminals. Therefore, a terminal can communicate through a unicast link if the number of terminals receiving multicast for a specific service is not large. At this time, the number of terminals is also a preset number and can be set in consideration of terminal characteristics, and is not limited to the above-described embodiment.

At this time, as an example, similar to what was described above, the preset number of switches from the multicast method to the unicast method may be signaled by the base station. As another example, the preset number may be determined by the terminal in consideration of terminal capabilities and terminal conditions, and is not limited to the above-described embodiment.

Meanwhile, in order to support the above-described terminal operation, the terminal may need to simultaneously support unicast and multicast links for the same service. More specifically, the terminal application can set up both multicast and unicast links for the same service. At this time, the terminal may use one of the communication methods among the links established based on the terminal's situation. That is, the terminal can use the multicast method based on the established link in certain cases. Alternatively, the terminal may use the unicast method based on the established link in certain cases.

At this time, considering the above, there is a need to support unicast and multicast communication methods for the same service, as shown in Table 5 below. Accordingly, IDs for each corresponding communication method can be set. As an example, in Table 5 below, both unicast and multicast communication methods may be supported for QoS A. At this time, the source ID and destination ID for QoS A can be set for each communication method.

[Table 5]

Additionally, as an example, when unicast and multicast are simultaneously configured for the same QoS, the terminal may determine whether to perform unicast or multicast communication according to conditions based on Table 6 below.

More specifically, the terminal can use either unicast or multicast based on the number of receiving terminals. At this time, the number of receiving terminals may be determined based on a preset number. That is, the terminal can perform unicast communication if the number is less than the preset number, and can perform multicast communication if the number exceeds the preset number.

Additionally, as an example, referring to Table 6, unicast or multicast method may be determined based on terminal capabilities. More specifically, when supporting unicast for a specific service, the number of unicast connections may be limited depending on terminal capabilities. For example, a terminal may support up to four unicast connections for a specific service. Accordingly, the terminal may determine that multicast communication will be performed when the number of connections exceeds 4. On the other hand, if the number of unicast connections does not exceed 4, the terminal may determine that unicast communication will be performed. However, the above-described capabilities are only one example and may be distinguished based on other terminal capabilities.

[Table 6]

Additionally, based on the above-described conditions, the application layer of the terminal can determine whether to perform unicast communication or multicast communication. At this time, along with the data to be transmitted to the lower layer, it can be indicated what communication method should be applied when transmitting this data and what the destination ID and source ID for the data are. The MAC layer of the terminal can transmit data according to the instructions of the above-mentioned upper layer, which is described in detail below.

As an example, Figure 13 is a diagram showing unicast and multicast link settings. At this time, as an example, unicast and multicast may be set simultaneously for the same service as described above. That is, when unicast and multicast are simultaneously configured for the same QoS, the terminal can perform unicast or multicast communication based on the above. As an example, one terminal 1310 may communicate with each of a plurality of terminals 1320, 1330, and 1340 in a unicast manner based on the conditions in Table 6 described above. At this time, if it is based on the unicast method, it may be easy to satisfy the service requirements for each individual terminal, but resource efficiency may be reduced, as described above. Additionally, as an example, one terminal 1310 may perform multicast communication with a plurality of terminals 1320, 1330, and 1340 based on the conditions in Table 6 described above. At this time, resource efficiency can be increased using the multicast method, but it may be difficult to satisfy the requirements for individual terminals, as described above.

As another example, considering the above-described Examples 1 and 2, when only a link for unicast is established for a specific V2X service, when only a link for multicast is established for a specific V2X service, and for a specific V2X service For this purpose, the case where links for both unicast and multicast are established can be considered. At this time, as an example, the link supported by the terminal may be signaled by the base station. As an example, the terminal may receive control information for V2X communication from the base station as in mode 3 described above. At this time, the base station may instruct the terminal to support only unicast links in consideration of the communication environment. Additionally, as an example, the base station may instruct the terminal to support only multicast links in consideration of the communication environment. Additionally, as an example, the base station may instruct the terminal to support both unicast and multicast links in consideration of the communication environment.

That is, the base station can indicate whether to support unicast and/or multicast links for each terminal, and for a specific V2X service, the communication method can be determined by considering the link supported by the terminal by the application layer as described above. It is not limited to the above-described embodiments.

As described above, in relation to V2X services, the terminal may perform sidelink communication based on unicast and/or multicast methods. At this time, as an example, as described above, the MAC layer of the terminal may receive at least one of a communication method, source ID, destination ID, and data for a specific service from the application layer. . At this time, the MAC layer of the terminal that has received the above-described information may perform different operations depending on the communication method.

More specifically, as an example, the terminal may use different MAC PDU formats to distinguish between unicast and multicast. As an example, one of the essential identifiers for unicast/multicast communication may be the L2 ID, as described above. Therefore, to avoid address collisions, different MAC PDUs can be used, and through this, each communication method can be distinguished. At this time, as an example, the MAC PDU format may be divided into a V field. At this time, the V field value may be set to different values in unicast and multicast. That is, different MAC PDU formats can be used by using different V field values in unicast and multicast. Meanwhile, as an example, in V2X sidelink, the above-described unicast and multicast can be distinguished for each service. That is, unicast or multicast can be set for each QoS.

At this time, as an example, FIG. 14 is a diagram showing the MAC PDU format used when the terminal performs unicast/multicast communication.

At this time, as described above in FIG. 14, the MAC PDU can be configured in consideration of the V2X sidelink. As an example, the MAC PDU used in a V2X sidelink may consist of a MAC header, a MAC Service Data Unit (SDU), and optional padding. Referring to FIG. 14, the MAC PDU header may have multiple MAC PDU subheaders. Additionally, the Sidelink-Shared Channel (SL-SCH) subheader may be the first header in the MAC PDU. At this time, the SL-SCH subheader may have header fields of V/R/R/R/R/SRC/DST, as shown in FIG. 15. Additionally, the subheader corresponding to the MAC SDU may be composed of six fields: R/F/LCID/L. Alternatively, the subheader corresponding to the MAC SDU may be composed of R/R/LCID. At this time, R/R/LCID may correspond to the MAC PDU subheader corresponding to padding. Meanwhile, as described above, FIG. 15 is a diagram showing the MAC subheader used when a terminal performs unicast/multicast communication. Additionally, Figure 16 may be a subheader for the MAC SDU and padding used when the terminal performs unicast/multicast communication.

At this time, as an example, referring to FIG. 15, the size of the MAC PDU header may be variable and may be composed of the following fields. In more detail, a “V field” may be configured. At this time, the V field can represent the version number of the MAC PDU format with a total of 4 bits. For example, in LTE D2D and LTE V2X, three format versions could be defined: “0001”, “0010”, and “0011”. At this time, “0001” may indicate that it can be used for unicast purposes in D2D. Additionally, “0010” may indicate that it can be used for group cast purposes in D2D. Additionally, “0011” may indicate that it can be used for broadcast purposes in V2X. At this time, the DST field of the MAC PDU header can use 24 bits. That is, unlike before, it may be necessary to define the V field to be used for unicast and multicast purposes in V2X based on each service based on the above. As an example, “0100” may be used in unicast based on V2X service for the V field described above. Additionally, for the above-mentioned V field, “0101” can be used in multicast based on V2X service. Additionally, as an example, the V field values for unicast and multicast based on the V2X service described above may be set to different values. That is, it can be set to any one of the 4-bit V fields excluding the values used by LTE D2D and LTE V2X, and is not limited to the above-described embodiment.

Additionally, as an example, unicast in D2D could be intended to support 1:1 communication between a relay terminal (relay-UE) and a remote terminal (remote-UE). On the other hand, unicast in V2X may be intended to support 1:1 communication for each V2X service. In other words, even between the same terminals, multiple unicast links can be established based on the V2X service. Therefore, the purpose of V2X unicast communication, which supports unicast connection for each service, and D2D unicast communication, which supports terminal-to-device unicast connection, may be different, and the above-mentioned V field can be set based on this. there is. In other words, a new “V field” to be used for unicast purposes in V2X may be defined, and may be different from the existing one in that it is service-based.

Additionally, as an example, the SL-SCH subheader may include an “SRC field”. At this time, the SRC field has a total of 24 bits and can indicate the ID (Source Layer-2 ID) of the source terminal. At this time, the ID of the source terminal may be set by the upper layer, as described above. At this time, in V2X unicast, a different terminal ID can be set for each service. Likewise, in V2X multicast, a different terminal ID may be set for each service. That is, different terminal IDs can be set based on the service, and are not limited to the above-described embodiment.

Additionally, as an example, the SL-SCH subheader may include a “DST field”. At this time, the DST field represents the ID of the destination and can be set by the upper layer. The DST field can be 16 bits or 24 bits. At this time, the expression method of the ID may vary depending on the number of supported bits. For example, if the DST field is 24 bits, the DST field may be set to “Destination Layer-2 ID”. As another example, if the DST field is 16 bits, the DST field may be set to the most significant 16 bits of “Destination Layer-2 ID”. That is, it can be set differently based on the number of bits supported.

At this time, as an example, when the DST field is 16 bits, the SL-SCH subheader may be configured as shown in (a) of FIG. 15. On the other hand, when the DST field is 24 bits, the SL-SCH subheader can be configured as shown in (b) of FIG. 15, and is not limited to the above-described embodiment.

Meanwhile, with regard to the V field described above, when the V field is set to “0001”, the terminal can support D2D group cast. At this time, the DST field may indicate the D2D group cast ID based on the V field.

Additionally, as an example, when the V field is set to “0010”, the terminal can support D2D unicast. At this time, the DST field may indicate the ID of D2D unicast based on the V field.

Additionally, as an example, if the V field is set to “0100 (or a value that supports V2X unicast)”, the terminal may support V2X unicast. At this time, the DST field may indicate the unicast ID of V2X based on the V field.

Additionally, as an example, if the V field is set to “0101 (or a value that supports V2X multicast)”, the terminal may support V2X multicast. At this time, the DST field may indicate a V2X multicast ID based on the V field.

Additionally, as an example, subheaders for MAC SDU and padding may be as shown in FIG. 16. At this time, as an example, the “LCID field” may indicate a logical channel ID. At this time, one LCID field may exist for each MAC SDU or padding.

Additionally, as an example, the “L field” may be a field indicating the length of the MAC SDU. At this time, there may be one L field per MAC PDU subheader except for the last subheader. Additionally, as an example, the size of the L field may be indicated by the F field.

Additionally, as an example, the “F field” represents the size of the L field with 1 bit, as described above. At this time, there is one F field per MAC PDU subheader, with 0 representing 8 bits and 1 representing 16 bits. Additionally, as an example, the “R field” is a reserved bit and can be set to 0.

At this time, as an example, when the terminal performs unicast communication based on the MAC PDU described above, the terminal may perform the following operations.

More specifically, when the terminal transmits data, the terminal may receive from the upper layer at least one of the data to be transmitted, the communication method to be applied, the destination ID for the data, and the source ID.

At this time, as an example, when the upper layer instructs to transmit data by unicast, the terminal can set the V field to the value “0100”. That is, the terminal may indicate that the MAC PDU is for V2X unicast purposes. Additionally, as an example, the terminal may set the “Destination Layer-2 ID” set from the upper layer in the DST field. Additionally, the terminal can set “Source Layer-2 ID” in the SRT field to indicate what service the data of the corresponding MAC PDU is intended for and who the sender of the data is.

At this time, as an example, the terminal completes the configuration of the SL-SCH subheader by setting the V field for unicast, the DST field and the SRC field for service, and then configures the MAC SDU and the subheader for the MAC SDU. Data for services that support unicast can be transmitted. At this time, the configuration of the entire MAC PDU can be completed by configuring the above-described MAC SDU and subheaders for the MAC SDU and configuring padding bits for the remaining resources. Afterwards, the terminal may instruct the physical layer to transmit the above-described MAC PDU through a unicast link.

Additionally, as an example, at the target terminal receiving data, the terminal may first check the destination ID (Destination ID) of the SCI. At this time, if the destination ID is the same as the destination ID set in the terminal (i.e., if it is a service supported by the terminal), the terminal may attempt to decode the corresponding MAC PDU. At this time, the terminal can check the V field and DST field of the SL-SCH subheader of the MAC PDU to determine which communication method and which service the data is for. For example, if the V field is set to 0100, the terminal can confirm that the data is for unicast. Additionally, the target terminal can check the DST field to determine what service the data is for. Additionally, the target terminal can check the SRT field to confirm the sender of the data. Afterwards, the terminal can receive data by decoding the subheader for the MAC SDU and the MAC SDU, and transmit the received data to a higher layer.

At this time, as an example, when the terminal performs unicast communication based on the MAC PDU described above, the terminal may perform the following operations.

More specifically, when the terminal transmits data, the terminal may receive from the upper layer at least one of the data to be transmitted, the communication method to be applied, the destination ID for the data, and the source ID.

At this time, as an example, when the upper layer instructs to transmit data by unicast, the terminal can set the V field to the value “0100”. That is, the terminal may indicate that the MAC PDU is for V2X unicast purposes. Additionally, as an example, the terminal may set the “Destination Layer-2 ID” set from the upper layer in the DST field. Additionally, the terminal can set “Source Layer-2 ID” in the SRT field to indicate what service the data of the corresponding MAC PDU is intended for and who the sender of the data is.

At this time, as another example, the terminal completes the configuration of the SL-SCH subheader by setting the V field for multicast, the DST field and the SRC field for service, and then configures the MAC SDU and the subheader for the MAC SDU. Thus, data for services that support multicast can be transmitted. At this time, the configuration of the entire MAC PDU can be completed by configuring the above-described MAC SDU and subheaders for the MAC SDU and configuring padding bits for the remaining resources. Afterwards, the terminal may instruct the physical layer to transmit the above-described MAC PDU through the multicast group.

Additionally, as an example, at the target terminal receiving data, the terminal may first check the destination ID (Destination ID) of the SCI. At this time, if the destination ID is the same as the destination ID set in the terminal (i.e., if it is a service supported by the terminal), the terminal may attempt to decode the corresponding MAC PDU. At this time, the terminal can check the V field and DST field of the SL-SCH subheader of the MAC PDU to determine which communication method and which service the data is for. For example, if the V field is set to “0101”, the terminal can confirm that the data is for multicast. Additionally, the target terminal can check the DST field to determine what service the data is for. Additionally, the target terminal can check the SRT field to confirm the sender of the data. Afterwards, the terminal can receive data by decoding the subheader for the MAC SDU and the MAC SDU, and transmit the received data to a higher layer.

As described above, the terminal can perform unicast/multicast operations to transmit and receive data for advanced V2X services requiring low delay and high reliability.

At this time, for example, when the terminal performs a unicast/multicast operation, the terminal needs to identify the receiving terminal. For example, a procedure may be required to confirm whether the receiving terminal has correctly received the data. Therefore, the terminal may need to check the terminal(s) performing unicast/multicast and update the status of the receiving terminal.

More specifically, the application layer of the terminal may periodically search for the existence of a terminal supporting a specific service. At this time, if there is a terminal supporting the service nearby, the application layer of the terminal may add the above-described terminal to the receiving terminal list. Additionally, the application layer of the terminal may perform a link/group setting process for unicast and/or multicast communication.

At this time, as an example, the application layer of the terminal may periodically request feedback on whether the service is supported from the terminal stored in the receiving terminal list. Here, the cycle can be set according to the requirements of the corresponding service. For example, if a service must meet a delay requirement of less than 10ms, the transmitting terminal (application layer) may request feedback from the receiving terminal (application layer) at a period shorter than 10ms. The transmitting terminal can set different period values for each unicast link or multicast group depending on service requirements.

For example, if the location of the receiving terminal (or receiving terminals) changes or the receiving terminal no longer supports the service, messages may not be transmitted to or received from the receiving terminal. That is, the application connection to the receiving terminal may be disconnected, making it impossible to receive feedback from the above-described terminal within the set reception response period. At this time, as an example, the terminal may update the receiving terminal list by deleting terminal information (e.g. Source ID) about the receiving terminal (or receiving terminals) described above for the corresponding service from the receiving terminal list.

More specifically, the validity of a link may be determined based on a “keepalive” procedure. At this time, in the “keepalive” procedure, there may be a terminal (hereinafter referred to as trigger terminal, transmitting terminal) that triggers the above-described procedure and requests transmission of a response message. Additionally, there may be a terminal (response terminal) that transmits a response message based on the keepalive request described above. At this time, as an example, the trigger terminal may use a predetermined timer and counter when performing a “keepalive” procedure. As an example, the timer may be defined as “T4114”, and the above-described timer may be started/restarted when the “keepalive” procedure is triggered. Additionally, as an example, the above-described timer may be started/restarted each time the terminal receives a message or data through the PC5 link. Additionally, the counter can be used for the purpose of checking the response in the “keepalive” procedure, and the counter value can be set to 0 during initial setup of the link.

As an example, if the “T4114” timer is running, the terminal that triggered the “keepalive” procedure can stop the timer and generate a “DIRECT_COMMUNICATION_KEEPALIVE” message containing the counter value for the link. At this time, after the terminal generates the above-described “DIRECT_COMMUNICATION_KEEPALIVE” message, the source ID and destination ID along with the above-mentioned message may be transmitted to the lower layer in order to transmit the above-mentioned message. At this time, the timer defined as “T4115” can be started. Afterwards, the terminal that received the “DIRECT_COMMUNICATION_KEEPALIVE” message can notify that the link is valid by responding. At this time, the response message may be a “DIRECT_COMMUNICATION_KEEPALIVE_ACK” message. In the above-mentioned message, the counter value may be set to be the same as the counter value included in the received “DIRECT_COMMUNICATION_KEEPALIVE” message. At this time, when the terminal receives the above-described ACK message, it can stop the “T4115” timer and start the “T4114” timer. Accordingly, the keepalive process can be completed by increasing the counter value according to the keepalive procedure with the counter value of 0 for the link as the initial value. The counter value is applied according to the max value set in the RRC message.

On the other hand, if the terminal that transmitted the “DIRCT_COMMUNICATION_KEEPALIVE” message does not receive the response message until the “T4115” timer expires, the terminal may retransmit the messages described above until the maximum number of retransmissions is reached. At this time, when the maximum number of retransmissions is reached, the terminal can stop the “keepalive” procedure and delete the above-mentioned terminal from the receiving terminal list.

As described, a terminal that supports V2X can manage/update the receiving terminal list by performing the keepalive procedure set for each service.

As another example, the application layer of the terminal may periodically configure/update the receiving terminal list based on the destination ID and source ID of the received data. The MAC layer of the terminal can check the destination ID and source ID of the data through receiving MAC PDU. At this time, the MAC layer of the terminal may transmit the ID information along with the above-described data to the upper layer. The application layer that receives the information may periodically update the list of receiving terminals for a specific service according to period information set according to service requirements.

More specifically, unicast/multicast communication can be performed for the same QoS, as described above. At this time, it is possible to know at what cycle messages are transmitted between terminals performing the above-described communication. Therefore, a timer can be set in each receiving terminal according to the above-mentioned period. At this time, the terminal can be maintained in the receiving terminal list by starting/restarting the timer every time data is received from the receiving terminal. On the other hand, if the location of the terminal changes and communication is no longer possible, the terminal may not be able to receive the message even if it is time to receive the message. Therefore, if the terminal does not receive a message from the terminal until the timer expires, the terminal can be deleted from the receiving terminal list. The terminal can set a timer for each link/group to support unicast/multicast services. At this time, different timer values can be set according to service characteristics required for each link/group.

As another example, the terminal may configure/update the receiving terminal list based on the RSRP measurement value of each receiving terminal. If the RSRP measured from the receiving terminal is below a certain threshold, the terminal may determine that communication with the corresponding terminal is difficult and may be deleted from the receiving terminal list. On the other hand, if the RSRP measured from the receiving terminal is above a certain threshold, the terminal determines that communication with the corresponding terminal is possible and can maintain it in the receiving terminal list. The threshold according to the service support may use a value set by the base station.

The application layer of the terminal can manage the receiving terminal list in the same way as above. At this time, for example, the surrounding environment may continue to change depending on the driving path and speed of the terminal, and there may be no terminal supporting the service at a specific point in time. That is, there may not be any terminal in the receiving terminal list. As an example, in the above-described case, the terminal may not transmit its information. In other words, the purpose of unicast/multicast is to exchange information between terminals that support specific services. If the receiving terminal does not exist, transmission may not be performed. Therefore, the terminal can prevent unnecessary transmission by deactivating the service.

At this time, the terminal (transmitter) may trigger the following inactivity operation if the receiving terminal is not detected for a set period of time related to the inactivity operation. For example, the time when it is determined that the receiving terminal does not exist can be set as the triggering time. Or, after determining that the receiving terminal does not exist, wait for a signal from the receiving terminal for a set tolerance time (waiting time), and if there is no signal within the t_time, determine that the receiving terminal does not exist, Triggering is possible. Here, the tolerance time (waiting time) is a time that prohibits triggering of service deactivation, and the value of t_time can be set in consideration of the service. In this regard, a deactivation triggering prohibition timer can be set using the timer value. The service deactivation may be triggered by the application layer of the terminal.

Figure 17 is a diagram showing a method of updating a receiving terminal list for a specific service according to the present invention.

Referring to FIG. 17, there may be a list of receiving terminals for a specific service of a specific terminal. As an example, terminals that support a specific service of terminal A (1710) may be terminal B (1720), terminal C (1730), and terminal D (1740). At this time, if it is confirmed that the receiving terminal does not support the service, the receiving terminal list can be updated. As an example, in FIG. 17, terminal A (1710) considers feedback, considers the keepalive procedure, or checks terminal C (1730) that does not support the service based on MAC PDU reception or RSRP measurement values, and creates a list of receiving terminals. The terminal C (1730) can be deleted.

Figure 18 is a diagram showing service deactivation according to the present invention.

Referring to FIG. 18, the terminal can check the receiving terminal list (S1810). The application layer of the terminal can manage the receiving terminal list. At this time, when the application layer of the terminal confirms that the receiving terminal list for a specific service is empty (S1820), the terminal may determine that there is no longer a need to transmit data for the above-mentioned service. Here, the terminal can perform deactivation by considering the set t_time value.

On the other hand, if the receiving terminal (or receiving terminals) exists in the receiving terminal list, the terminal can perform data transmission as described above. (S1830)

For example, in relation to step S1820, when the application layer of the terminal confirms that the receiving terminal list for a specific service is empty, the application layer may no longer transmit data for the corresponding service to the lower layer. Additionally, unnecessary data transmission can be prevented by instructing the lower layer to disable the service. (S1840) At this time, based on the above-described instructions, the lower layer (MAC, RLC, PDCP) of the terminal may discard the data stored in the SLRB (Sidelink Radio Bearer) for the corresponding service. Additionally, the terminal may discard data stored in the corresponding logical channel and empty the HARQ buffer in which the corresponding data is stored. (S1850) That is, unnecessary transmission can be prevented based on the above-described operation.

Figure 19 may be a diagram showing data flow according to the present invention. At this time, as an example, referring to FIG. 19, the lower layer of the terminal may be composed of Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), and Media Access Control (MAC) layers. . Additionally, the terminal can configure a radio bearer according to the QoS of the data to be served or generated by the terminal. Additionally, the terminal may be configured with logical channels.

At this time, the above-described radio bearer may be configured to transmit or receive data packets with a specific QoS. As an example, a bearer configured to transmit sidelink data among radio bearers may be referred to as a sidelink radio bearer (SLRB).

The SDAP layer of the terminal can determine which SLRB it should be transmitted through according to the QoS of each packet generated from the application layer of the terminal. For example, it may be determined that packets for QoS A will be transmitted to SLRB A, packets for QoS B will be transmitted to SLRB B, and packets for QoS C will be transmitted to SLRB C.

The PDCP layer may have multiple PDCP entities, and the SLRB may have a one-to-one mapping relationship with one PDCP entity. The PDCP layer may be a layer that performs a header compression function that reduces unnecessary information, data packet reordering, and duplicate data packet detection functions to efficiently transmit data packets transmitted to the SLRB. Additionally, the PDCP layer can secure data packets and retransmit data packets that were not properly received at the receiving end when resetting the RRC connection.

The RLC layer can split data packets to fit the data size requested by the lower layer, and can support three modes to guarantee the various QoS required by SLRB. At this time, the three modes can be RLC-TM (Transport Mode), RLC-UM (Unacknowledged Mode), and RLC-AM (Acknowledged Mode).

In addition, the logical channel is a channel that connects MAC and RLC. The logical channel used is different depending on the type of data, and data packets that have completed processing in the RLC layer can be transmitted to the MAC layer through the logical channel. .

The MAC layer can generate a MAC PDU from data packets received through a logical channel, and the generated MAC PDU can be stored in the HARQ buffer. As described above, after the MAC PDU is successfully received, the terminal can discard the MAC PDU stored in the HARQ buffer.

Based on the operations described above, the terminal can transmit data. Therefore, data may be stored in the HARQ buffer of SLRB, PDCP, RLC, logical channel, and MAC. At this time, when a service deactivation instruction is received from the application layer, the terminal can prevent unnecessary transmission by deleting data corresponding to the QoS of the above-mentioned service.

For example, when instructed to deactivate the service for QoS A, the terminal may delete data stored in the PDCP entity, RLC entity, and logical channel for SRLB A and SLRB A. Additionally, the HARQ buffer in which the MAC PDU composed of data received from the above-mentioned logical channel is stored can be emptied.

Additionally, as an example, as described above, when there is no receiving terminal in the receiving list, service deactivation may be instructed. At this time, as an example, the application layer of the terminal may manage the receiving terminal list, as described above. When the terminal's application layer confirms that the receiving terminal list for a specific service is empty, the terminal may determine that there is no longer a need to transmit data for the service. At this time, the application layer may no longer transmit data for the corresponding service to the lower layer. Additionally, the list of receiving terminals can be passed to the lower layer of the terminal to implicitly instruct to deactivate the service.

As an example, the lower layer of the terminal that received the above-described receiving terminal list can check the receiving terminal list. At this time, if it is confirmed that no terminal exists in the list, the terminal can recognize that the corresponding service is being deactivated. That is, service deactivation may be implicitly instructed. At this time, the lower layer (MAC, RLC, PDCP) of the terminal can delete data stored in the SLRB for the corresponding service. Additionally, data stored in the corresponding logical channel can be deleted. Additionally, the HARQ buffer where the corresponding data is stored can be emptied. In other words, the terminal can prevent unnecessary transmission through the above-described dynamic.

At this time, referring to the above-mentioned FIG. 19, when deactivation of QoS A is implicitly instructed, the terminal can delete data stored in the PDCP entity, RLC entity, and logical channel for SRLB A and SLRB A. In addition, the HARQ buffer in which the MAC PDU composed of data received from the above-described logical channel is stored may be emptied, and is not limited to the above-described embodiment.

Figure 20 is a diagram showing a method of transmitting a message based on the communication method for the service.

Referring to FIG. 20, the MAC layer of the terminal can obtain communication method, source ID, and destination ID information for the first service from the application layer. (S2010) At this time, as described above with reference to FIGS. 1 to 19, the communication method may be determined based on the V2X service. That is, the first service is a specific service, and a unicast or multicast transmission method may be applied to each service.

Next, when the communication method for the first service is unicast (S2020), the terminal sends a message including information indicating unicast, a source ID set based on unicast, and a destination ID set based on unicast. It can be transmitted to another terminal. (S2030) At this time, as in Example 3 described above, the information indicating unicast may be the V field. In addition, the source ID and destination ID are determined based on the unicast communication method, and information regarding this can be included and transmitted, as described above.

Additionally, as an example, when the communication method for the first service is multicast (S2020), the terminal includes information indicating multicast, a source ID set based on multicast, and a destination ID set based on multicast. Messages can be sent to other terminals. (S2040) At this time, as in the above-described embodiment 3, the information indicating multicast may be the V field. Additionally, the source ID and destination ID are determined based on the multicast communication method, and information regarding this may be included and transmitted, as described above.

Figure 21 is a diagram showing the configuration of a base station device and a terminal device according to the present disclosure.

The base station device 2100 may include a processor 2120, an antenna unit 2112, a transceiver 2114, and a memory 2116.

The processor 2120 performs baseband-related signal processing and may include an upper layer processing unit 2130 and a physical layer processing unit 2140. The upper layer processing unit 2130 may process operations of a MAC (Medium Access Control) layer, RRC (Radio Resource Control) layer, or higher layers. The physical layer processing unit 2140 may process physical (PHY) layer operations (e.g., uplink reception signal processing, downlink transmission signal processing, sidelink transmission signal processing, sidelink reception signal processing). . In addition to performing baseband-related signal processing, the processor 2120 may also control the overall operation of the base station device 2100.

The antenna unit 2112 may include one or more physical antennas, and when it includes multiple antennas, it may support Multiple Input Multiple Output (MIMO) transmission and reception. Transceiver 2114 may include a radio frequency (RF) transmitter and an RF receiver. The memory 2116 may store information processed by the processor 2120, software related to the operation of the base station device 2100, an operating system, applications, etc., and may also include components such as buffers.

According to the present invention, the processor 2120 of the base station device 2100 can check resource pool information to schedule resources used by each terminal device 2150 to transmit V2X control information and/or data. Additionally, as an example, the processor 2120 may provide information about the resource pool to the corresponding terminal device 2150. Additionally, as an example, the processor 2120 may check information about the region (or zone) to which the resource pool is applied. At this time, the processor 2120 may provide information about the region (or zone) to the terminal device 2150.

At this time, as an example, the processor 2120 may provide the above-described resource pool information and information about the region (or zone) to the terminal device 2150 through RRC signaling.

Additionally, as an example, the processor 2120 may provide the terminal device 2150 with a value for a timer used when the terminal device 2150 updates the receiving terminal list. As an example, the processor 2120 may provide the value for the above-described timer to the terminal device 2150 through RRC signaling. Additionally, as an example, the processor 2120 may provide the terminal device 2150 with a value for a timer that triggers deactivation based on detection of the receiving terminal. As an example, the processor 2120 may provide the above-described timer value to the terminal device 2150 through RRC signaling.

Additionally, as an example, the processor 2120 may perform procedures regarding UE Capability with the terminal device 2150. At this time, the processor 2120 may provide the terminal device 2150 with information about the number of service support terminals as reference information for the terminal device 2150 to set a unicast/multicast link/group in the terminal capability procedure. there is. Additionally, as an example, the processor 2120 may further provide other standard information (e.g. service requirements) for the terminal device 2150 to set up a unicast/multicast link/group in the terminal capability procedure, and may further provide other standard information (e.g. service requirements) in the terminal capability procedure. It is not limited to examples.

Additionally, as an example, the processor 2120 may provide the above-described information to the terminal device 2150 through RRC signaling.

The terminal device 2150 may include a processor 2170, an antenna unit 2162, a transceiver 2164, and a memory 2166.

The processor 2170 performs baseband-related signal processing and may include an upper layer processing unit 2180 and a physical layer processing unit 2190. The upper layer processing unit 2180 can process operations of the MAC layer, RRC layer, or higher layers. The physical layer processing unit 2190 may process PHY layer operations (e.g., downlink received signal processing, uplink transmitted signal processing, sidelink transmitted signal processing, sidelink received signal processing). In addition to performing baseband-related signal processing, the processor 2170 may also control the overall operation of the terminal device 2150.

The antenna unit 2162 may include one or more physical antennas, and may support MIMO transmission and reception when it includes a plurality of antennas. Transceiver 2164 may include an RF transmitter and an RF receiver. The memory 2166 may store information processed by the processor 2170, software related to the operation of the terminal device 2150, an operating system, applications, etc., and may also include components such as buffers.

The processor 2170 of the terminal device 2150 may be configured to implement the operations of the terminal in the embodiments described in the present invention.

As an example, the processor 2170 may include a MAC PDU generator 2184. At this time, the MAC generator 2184 may generate a MAC PDU based on the communication method, destination ID, and source ID information.

Additionally, the upper layer processing unit 2180 of the processor 2170 can control/manage the deactivation operation using the deactivation tolerance time (waiting time). When the service deactivation unit 2188 receives a deactivation instruction for a specific service supporting unicast and/or multicast from the upper layer processing unit 2180, it may deactivate the service by deleting data.

Meanwhile, the MAC layer of the terminal as the upper layer processing unit 2180 of the terminal device 2150 can obtain communication method, source ID, and destination ID information for the first service from the application layer. At this time, the terminal device 2150 may configure a message to be transmitted to another terminal based on the communication method for the first service. For example, when the communication method for the first service is unicast, the terminal device 2150 sends a message including information indicating unicast, a source ID set based on unicast, and a destination ID set based on unicast. can be transmitted to another terminal, as described above. Additionally, as an example, when the communication method for the first service is multicast, the terminal device 2150 includes information indicating multicast, a source ID set based on multicast, and a destination ID set based on multicast. A message can be transmitted to another terminal, as described above.

According to the present invention, the processor 2170 can manage/update the receiving terminal list for each group by considering feedback/response, keepalive operation, MAC PDU reception, or RSRP measurement values for each unicast/multicast link and group. .

The processor 2170 can set a timer for each link/group to support unicast/multicast services in relation to list management/update. At this time, different timer values can be set according to service characteristics required for each link/group.

Additionally, the processor 2170 may trigger a service deactivation operation by considering the presence or absence of a receiving terminal. At this time, a tolerance time (waiting time) that can hold deactivation triggering can be set in relation to the presence or absence of the receiving terminal and the presence or absence. The t time can be set differently for each unicast/multicast service link/group. Additionally, in relation to the described time, the processor 2170 may be provided with a timer. In addition, the matters described in the examples of the present invention may be equally applied to the operations of the base station device 2100 and the terminal device 2150, and overlapping descriptions will be omitted.

Exemplary methods of the present disclosure are expressed as a series of operations for clarity of explanation, but this is not intended to limit the order in which the steps are performed, and each step may be performed simultaneously or in a different order, if necessary. In order to implement the method according to the present disclosure, other steps may be included in addition to the exemplified steps, some steps may be excluded and the remaining steps may be included, or some steps may be excluded and additional other steps may be included.

The various embodiments of the present disclosure do not list all possible combinations but are intended to explain representative aspects of the present disclosure, and matters described in the various embodiments may be applied independently or in combination of two or more.

Additionally, various embodiments of the present disclosure may be implemented by hardware, firmware, software, or a combination thereof. For hardware implementation, one or more ASICs (Application Specific Integrated Circuits), DSPs (Digital Signal Processors), DSPDs (Digital Signal Processing Devices), PLDs (Programmable Logic Devices), FPGAs (Field Programmable Gate Arrays), general purpose It can be implemented by a processor (general processor), controller, microcontroller, microprocessor, etc.

The scope of the present disclosure is software or machine-executable instructions (e.g., operating system, application, firmware, program, etc.) that cause operations according to the methods of various embodiments to be executed on a device or computer, and such software or It includes non-transitory computer-readable medium in which instructions, etc. are stored and can be executed on a device or computer.

Base Station: 2100 Processor: 2120
Upper layer processing unit: 2130 Physical layer processing unit: 2140
Antenna unit: 2112 Transceiver: 2114
Memory: 2116 Terminal: 2150
Processor: 2170 Upper layer processor: 2180
MAC PDU creation unit: 2184 Service deactivation unit: 2188
Physical layer processing unit: 2190 Antenna unit: 2162
Transceiver: 2164 Memory: 2166

Claims (8)

In a method for a terminal to perform communication in a wireless communication system,
A media access control (MAC) layer of a first terminal acquires communication method information for a first service from an application layer, where the communication method of the first service is a method supporting the first service. At least one of a unicast method and a multicast method is determined based on the number of terminals and the terminal capability information;
determining, by the MAC layer of the first terminal, a source ID and a destination ID based on the determined communication method of the first service; and
Transmitting data for the first service to a second terminal based on the physical (PHY) layer of the first terminal,
The first terminal instructs the second terminal a communication method of the first service based on information indicating the communication method in data for the first service,
Data for the first service is transmitted to the second terminal based on a media access control (MAC) packet data unit (PDU) consisting of at least one of a V field, a DST field, and an SRT field, and the determined source ID and the destination An ID is assigned to the MAC PDU,
The information indicating the communication method in the data for the first service is included in any one of the V fields consisting of 4 bits, excluding the values used by LTE (long term evolution) D2D (device to device) and LTE V2X. Method of communication, dictated based on.
According to clause 1,
The terminal capability information indicates a terminal capability (UE capability) indicating the number of terminals receiving data for the first service and the number of connections possible in the unicast method for the first service. How to carry out ,communication .
According to clause 1,
The communication method of the determined first service is switched to at least one of the unicast method and the multicast method according to the preconfigured number of terminals signaled by the base station.
According to clause 1,
A communication method in which the application layer of the first terminal periodically checks the receiving terminal list and deletes or deactivates terminals that do not support the first service.
In a terminal performing communication in a wireless communication system,
transceiver;
Includes a processor connected to the transceiver;
The processor,
The media access control (MAC) layer of the first terminal obtains communication method information for the first service from the application layer, where the communication method of the first service is the terminal supporting the first service. is determined to be at least one of a unicast method and a multicast method based on the number and capability information of the terminal;
The MAC layer of the first terminal determines a source ID and a destination ID based on the determined communication method of the first service; and
Data for the first service is transmitted to the second terminal based on the physical (PHY) layer of the first terminal,
The first terminal instructs the second terminal a communication method of the first service based on information indicating the communication method in data for the first service,
Data for the first service is transmitted to the second terminal based on a media access control (MAC) packet data unit (PDU) consisting of at least one of a V field, a DST field, and an SRT field, and the determined source ID and the destination An ID is assigned to the MAC PDU,
The information indicating the communication method in the data for the first service is any one of the V field consisting of 4 bits excluding the value used by LTE (long term evolution) D2D (device to device) and LTE V2X Terminal indicated based on.
According to clause 5,
The terminal capability information includes a terminal capability (UE capability) indicating the number of terminals receiving data for the first service and the number of possible connections in the unicast method for the first service.
According to clause 5,
The determined communication method is switched to at least one of the unicast method and the multicast method according to the pre-configured number of terminals signaled by the base station.
According to clause 5,
The application layer of the first terminal periodically checks the receiving terminal list and deletes or deactivates terminals that do not support the first service.

Images