JP2023513585A - 不連続受信タイマ維持方法及び端末 - Google Patents

不連続受信タイマ維持方法及び端末 Download PDF

Info

Publication number
JP2023513585A
JP2023513585A JP2022548681A JP2022548681A JP2023513585A JP 2023513585 A JP2023513585 A JP 2023513585A JP 2022548681 A JP2022548681 A JP 2022548681A JP 2022548681 A JP2022548681 A JP 2022548681A JP 2023513585 A JP2023513585 A JP 2023513585A
Authority
JP
Japan
Prior art keywords
harq
harq process
terminal
timer
timer corresponding
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2022548681A
Other languages
English (en)
Other versions
JP7420955B2 (ja
Inventor
亜利 趙
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Datang Mobile Communications Equipment Co Ltd
Original Assignee
Datang Mobile Communications Equipment Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Datang Mobile Communications Equipment Co Ltd filed Critical Datang Mobile Communications Equipment Co Ltd
Publication of JP2023513585A publication Critical patent/JP2023513585A/ja
Application granted granted Critical
Publication of JP7420955B2 publication Critical patent/JP7420955B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0225—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal
    • H04W52/0229—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal where the received signal is a wanted signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0225—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal
    • H04W52/0248—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal dependent on the time of the day, e.g. according to expected transmission activity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1812—Hybrid protocols; Hybrid automatic repeat request [HARQ]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1822—Automatic repetition systems, e.g. Van Duuren systems involving configuration of automatic repeat request [ARQ] with parallel processes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1848—Time-out mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/188—Time-out mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0212—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave
    • H04W52/0216—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave using a pre-established activity schedule, e.g. traffic indication frame
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0261—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level
    • H04W52/0274—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level by switching on or off the equipment or parts thereof
    • H04W52/028—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level by switching on or off the equipment or parts thereof switching on or off only a part of the equipment circuit blocks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/14—Direct-mode setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/23—Manipulation of direct-mode connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/28—Discontinuous transmission [DTX]; Discontinuous reception [DRX]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/18—Interfaces between hierarchically similar devices between terminal devices
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

本開示は、通信の技術分野に関し、不連続受信タイマ維持方法及び端末を提供している。当該不連続受信タイマ維持方法は、端末に適用されるものであり、直接通信インターフェースに対し、第一ハイブリッド自動再送要求（ＨＡＲＱ）プロセスに対応する伝送タイプに応じて、第一ＨＡＲＱプロセスに対応するタイマを管理することを含む。【選択図】 図４

Description

関連出願の相互参照
本願は、２０２０年２月１０日に中国で出願された中国特許出願第２０２０１００８５２８９．７号の優先権を主張し、その内容の全ては、参照により本願に組み込まれる。
本開示は、通信の技術分野に関し、特に、不連続受信タイマ維持方法及び端末に関する。
直接通信インターフェースについては、現在、いかなる省電力メカニズムもサポートされていないため、端末の電力消費が比較的速く、ユーザーエクスペリエンスが良くない。したがって、直接通信インターフェースの不連続受信（Ｄｉｓｃｏｎｔｉｎｕｏｕｓ Ｒｅｃｅｐｔｉｏｎ、ＤＲＸ）構成を導入する必要がある。現在、無線通信システムのＤＲＸは、端末とネットワークとの間のインターフェース（即ちＵｕインターフェース）にのみ適用可能であり、直接通信インターフェースには、まだＤＲＸメカニズムがないため、直接通信インターフェースでは、電力を節約できない。したがって、直接通信インターフェースに省電力メカニズムを導入する必要があり、その可能な方式は、直接通信インターフェースにＤＲＸメカニズムを導入することであるが、現在、直接通信インターフェースにおいて、ＤＲＸを如何に実現するかについては、開示されている解決案が未だにない。
本開示の実施例は、関連技術案に直接通信インターフェースのＤＲＸメカニズムがなくて、直接通信インターフェースの省電力を実現できないという問題を解決するために、不連続受信タイマ維持方法及び端末を提供する。
上記課題を解決するために、本開示の実施例は、端末に適用される不連続受信タイマ維持方法であって、
直接通信インターフェースに対し、第一ハイブリッド自動再送要求（ＨＡＲＱ）プロセスに対応する伝送タイプに応じて、第一ＨＡＲＱプロセスに対応するタイマを管理することを含む、不連続受信タイマ維持方法を提供する。
選択的に、前記伝送タイプがブロードキャストの場合、前記の第一ハイブリッド自動再送要求（ＨＡＲＱ）プロセスに対応する伝送タイプに応じて、第一ＨＡＲＱプロセスに対応するタイマを管理することは、
端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持しないことを含む。
選択的に、前記伝送タイプがマルチキャスト又はユニキャストの場合、前記の第一ハイブリッド自動再送要求（ＨＡＲＱ）プロセスに対応する伝送タイプに応じて、第一ＨＡＲＱプロセスに対応するタイマを管理することは、
端末が第一ＨＡＲＱプロセスに対応するタイマを維持しないことと、
前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持し、そうでなければ、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持しないことと、
端末が第一ＨＡＲＱプロセスに対応するタイマを維持することとのうち、１つを含む。
さらに、前記伝送タイプがマルチキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ送信を行う場合、前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持することは、
端末が、物理層直接通信共有チャネル（ＰＳＳＣＨ）伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記ＨＡＲＱ往復遅延タイマがタイムアウトする際に、前記端末が、少なくとも、前記第一ＨＡＲＱプロセスに対する他の端末からのＨＡＲＱフィードバックとしてＨＡＲＱ非確認フィードバックを１つ受信していれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることと、
端末が、ＰＳＳＣＨ伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることとのうち、１つを含む。
さらに、前記伝送タイプがマルチキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ受信を行う場合、前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持することは、
端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱフィードバックがＨＡＲＱ非確認フィードバックであれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることと、
端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることとのうち、１つを含む。
具体的に、前記の端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせる場合、前記不連続受信タイマ維持方法は、
前記ＨＡＲＱ再送タイマのランニング中の第一プリセット時間Ｔ内に、前記第一ＨＡＲＱプロセスに対する再送スケジューリングを受信していなければ、端末が前記ＨＡＲＱ再送タイマのランニングを停止させることを更に含み、
ここで、前記第一プリセット時間Ｔは、前記ＨＡＲＱ再送タイマのタイマ時間未満である。
さらに、前記伝送タイプがユニキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ送信を行う場合、前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持することは、
端末が、物理層直接通信共有チャネル（ＰＳＳＣＨ）伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記ＨＡＲＱ往復遅延タイマがタイムアウトする際に、前記端末が、前記第一ＨＡＲＱプロセスに対するユニキャスト通信相手方からのＨＡＲＱフィードバックとしてＨＡＲＱ非確認フィードバックを受信していれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることを含む。
さらに、前記伝送タイプがユニキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ受信を行う場合、前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持することは、
端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱフィードバックがＨＡＲＱ非確認フィードバックであれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることを含む。
さらに、前記端末が前記第一ＨＡＲＱプロセスを利用してデータ送信を行う場合、前記端末が第一ＨＡＲＱプロセスに対応するタイマを維持することは、
端末が、物理層直接通信共有チャネル（ＰＳＳＣＨ）伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることを含む。
さらに、前記端末が前記第一ＨＡＲＱプロセスを利用してデータ受信を行う場合、前記端末が第一ＨＡＲＱプロセスに対応するタイマを維持することは、
端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信した後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることを含む。
本開示の実施例は、メモリと、プロセッサと、前記メモリに記憶されて前記プロセッサ上で動作可能なプログラムとを含む端末であって、前記プロセッサによって前記プログラムが実行されると、
直接通信インターフェースに対し、第一ハイブリッド自動再送要求（ＨＡＲＱ）プロセスに対応する伝送タイプに応じて、第一ＨＡＲＱプロセスに対応するタイマを管理することが実現される、端末を更に提供する。
選択的に、前記伝送タイプがブロードキャストの場合、前記プロセッサによって、前記第一ハイブリッド自動再送要求（ＨＡＲＱ）プロセスに対応する伝送タイプに応じて、第一ＨＡＲＱプロセスに対応するタイマを管理するプログラムが実行されると、
端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持しないことが実現される。
さらに、前記伝送タイプがマルチキャスト又はユニキャストの場合、前記プロセッサによって、前記第一ハイブリッド自動再送要求（ＨＡＲＱ）プロセスに対応する伝送タイプに応じて、第一ＨＡＲＱプロセスに対応するタイマを管理するプログラムが実行されると、
端末が第一ＨＡＲＱプロセスに対応するタイマを維持しないことと、
前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持し、そうでなければ、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持しないことと、
端末が第一ＨＡＲＱプロセスに対応するタイマを維持することとのうち、１つが実現される。
さらに、前記伝送タイプがマルチキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ送信を行う場合、前記プロセッサによって、上述の前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持するプログラムが実行されると、
端末が、物理層直接通信共有チャネル（ＰＳＳＣＨ）伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記ＨＡＲＱ往復遅延タイマがタイムアウトする際に、前記端末が、少なくとも、前記第一ＨＡＲＱプロセスに対する他の端末からのＨＡＲＱフィードバックとしてＨＡＲＱ非確認フィードバックを１つ受信していれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることと、
端末が、ＰＳＳＣＨ伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることとのうち、１つが実現される。
さらに、前記伝送タイプがマルチキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ受信を行う場合、前記プロセッサによって、上述の前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持するプログラムが実行されると、
端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱフィードバックがＨＡＲＱ非確認フィードバックであれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることと、
端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることとのうち、１つが実現される。
具体的に、前記プロセッサによって、前記端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせるプログラムが実行された後、
前記ＨＡＲＱ再送タイマのランニング中の第一プリセット時間Ｔ内に、前記第一ＨＡＲＱプロセスに対する再送スケジューリングを受信していなければ、端末が前記ＨＡＲＱ再送タイマのランニングを停止させることが更に実現され、
ここで、前記第一プリセット時間Ｔは、前記ＨＡＲＱ再送タイマのタイマ時間未満である。
さらに、前記伝送タイプがユニキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ送信を行う場合、前記プロセッサによって、上述の前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持するプログラムが実行されると、
端末が、物理層直接通信共有チャネル（ＰＳＳＣＨ）伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記ＨＡＲＱ往復遅延タイマがタイムアウトする際に、前記端末が、前記第一ＨＡＲＱプロセスに対するユニキャスト通信相手方からのＨＡＲＱフィードバックとしてＨＡＲＱ非確認フィードバックを受信していれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることが実現される。
さらに、前記伝送タイプがユニキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ受信を行う場合、前記プロセッサによって、上述の前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持するプログラムが実行されると、
端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱフィードバックがＨＡＲＱ非確認フィードバックであれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることが実現される。
さらに、前記端末が前記第一ＨＡＲＱプロセスを利用してデータ送信を行う場合、前記プロセッサによって、前記端末が第一ＨＡＲＱプロセスに対応するタイマを維持するプログラムが実行されると、
端末が、物理層直接通信共有チャネル（ＰＳＳＣＨ）伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることが実現される。
さらに、前記端末が前記第一ＨＡＲＱプロセスを利用してデータ受信を行う場合、前記プロセッサによって、前記端末が第一ＨＡＲＱプロセスに対応するタイマを維持するプログラムが実行されると、
端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信した後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることが実現される。
本開示の実施例は、コンピュータプログラムを記憶したコンピュータ読取可能な記憶媒体であって、前記コンピュータプログラムがプロセッサによって実行されると、上記の不連続受信タイマ維持方法が実現される、コンピュータ読取可能な記憶媒体を更に提供する。
本開示の実施例は、端末であって、
直接通信インターフェースに対し、第一ハイブリッド自動再送要求（ＨＡＲＱ）プロセスに対応する伝送タイプに応じて、第一ＨＡＲＱプロセスに対応するタイマを管理するための管理モジュールを含む、端末を更に提供する。
本開示の有益な効果は、以下の通りである。
上記解決案は、直接通信インターフェースにおいて、ＨＡＲＱプロセスに対応する伝送タイプに応じて、ＨＡＲＱプロセスに対応するタイマを管理することで、直接通信インターフェースのＤＲＸメカニズムを実現し、直接通信インターフェースの省電力を実現している。
セルラネットワーク通信を示す模式図である。 ＤＲＸ手順を示す模式図である。 直接通信のネットワークアーキテクチャを示す模式図である。 本開示の実施例に係る不連続受信タイマ維持方法のフローを示す模式図である。 本開示の実施例に係る端末のモジュールを示す模式図である。 本開示の実施例に係る端末の構造を示す図である。
本開示の目的、技術案及び利点をより明確にするために、以下、図面及び具体的な実施例を通じて詳細に記述する。
先ず、本開示の実施例に関連するいくつかの概念について、次の通りに説明する。
一、セルラネットワーク通信
従来のセルラネットワーク通信では、端末とネットワーク側機器との間は、端末とネットワークとの間のインターフェース（即ちＵｕインターフェース）を介して上り／下りリンクデータ及び制御情報の伝送を行い、具体的なネットワークアーキテクチャを図１に示す。
二、セルラ通信システムの不連続受信（Ｄｉｓｃｏｎｔｉｎｕｏｕｓ Ｒｅｃｅｐｔｉｏｎ、ＤＲＸ）メカニズム
例えば長期進化（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ、ＬＴＥ）のような共有チャネルベースの移動通信システムでは、上り下りリンクデータの伝送は、基地局（ｅＮＢ）のスケジューラによって制御され、スケジューラは、あるユーザをスケジューリングすることを確定すると、どんなリソースにてデータを送信又は受信するかを、制御チャネルを介して端末に通知する。ユーザ機器（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ、ＵＥ、端末とも呼ばれる）は、制御チャネルを監視し、自分のスケジューリング情報が含まれていることを検出すると、制御チャネル上の指示に従って、データの送信（上りリンク）又は受信（下りリンク）を遂行する。アクティブ状態では、端末が、何時ｅＮＢによってスケジューリングされるかを確定できないため、よく使われる作動モードの１つとして、端末は、制御チャネルを連続的に監視し、その下りリンクスケジューリング制御チャネルが含まれているサブフレームの各々を解析して、スケジューリングされているかを判断する。このような作動方式によれば、端末のデータ量が多くなり、頻繁にスケジューリングされる場合は、高効率を得られる可能性がある。しかしながら、一部のトラフィックの場合は、データの到着頻度が低いため、端末がスケジューリングされる回数も少なくなり、もし端末が依然として制御チャネルを連続的に監視すれば、間違いなくその消費電力が増加してしまう。電力消費の問題を解決するために、セルラネットワーク通信システムは、ＤＲＸ作動モードを採用しており、この作動モードでは、端末が制御チャネルを周期的に監視するため、省電力の目的が達成される。
ＤＲＸの基本原理を図２に示す。その中で、継続監視時間（Ｏｎ ｄｕｒａｔｉｏｎ）は、ＵＥが制御チャネルを監視する期間であって、その無線周波数チャンネルがオンされ、制御チャネルが連続的に監視される期間を表し、Ｏｎ ｄｕｒａｔｉｏｎを除く他の時間では、ＵＥは、スリープ（Ｓｌｅｅｐ）状態にあり、その無線周波数リンクがオフされ、制御チャネルが監視されなくなることで、省電力の目的が達成される。Ｏｎ Ｄｕｒａｔｉｏｎは、周期的に現れるものであり（Ｃｙｃｌｅ）、その具体的な周期がｅＮＢからの構成によって実現される。
セルラネットワークのＤＲＸメカニズムは、データトラフィックの到着モデル、即ちデータパケットの到着が突発的なもの（データパケットの到着が発生したら、短時間内で多くのパケットが連続して到着すると理解されてもよい）を考慮している。このようなトラフィック到着特性に適応するために、ＬＴＥ ＤＲＸ手順は、より良好な省電力性能を達成するために、複数種類のタイマを採用するとともに、ハイブリッド自動再送要求（ＨＡＲＱ）手順と組み合せている。
１、本開示の実施例に関連するＤＲＸ関連タイマ
ハイブリッド自動再要求往復遅延タイマ（ＨＡＲＱ ＲＴＴ Ｔｉｍｅｒ）：下りリンクＤＲＸハイブリッド自動再送要求往復遅延タイマ（ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＤＬ）と、上りリンクＤＲＸハイブリッド自動再要求往復遅延タイマ（ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＵＬ）とに分けられ、その目的は、次回の再送が到来する前に制御チャネルを監視しないという可能性をＵＥに持たせ、より良好な省電力効果を達成することにある。下りリンクを例として、ＵＥ関連プロセスの物理上りリンク制御チャネル（ＰＵＣＣＨ）伝送後の最初のシンボルが開始されると、このタイマがオンされる。もし対応するＨＡＲＱプロセスにおけるデータの復号が、前回のＨＡＲＱ伝送後、成功しなかった（ＵＥからＮＡＣＫがフィードバックされた）場合、ＤＬ ＨＡＲＱ ＲＴＴ Ｔｉｍｅｒがタイムアウトした後、ＵＥは、下りリンクＤＲＸ再送タイマ（ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬ）をオンする。もし対応するＨＡＲＱプロセスにおけるデータの復号が、前回のＨＡＲＱ伝送後、成功した（ＵＥからＡＣＫがフィードバックされた）場合、ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＤＬタイマがタイムアウトした後、ＵＥは、ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬをスタートさせない。もし現在ｄｒｘ－ＨＡＲＱ－ＲＴＴ－ＴｉｍｅｒＤＬのみがランニングされている場合、ＵＥは、制御チャネルを監視しない。
ハイブリッド自動再送要求再送タイマ（ＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅｒ）：ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＤＬ又は上りリンクＤＲＸ再送タイマ（ｄｒｘ－ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅｒＵＬ）に分けられる。下りリンクを例として、ＤＬ ＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅｒのランニング中に、ＵＥは、制御シグナリングを監視して、対応するＨＡＲＱプロセスの再送スケジューリングを待つ。
三、直接通信
直接通信とは、近接する端末が近距離範囲内で直接通信リンク（Ｓｉｄｅｌｉｎｋとも呼ばれる）を介してデータ伝送可能な方式を指す。Ｓｉｄｅｌｉｎｋリンクに対応する無線インターフェースは、直接通信インターフェースと呼ばれ、Ｓｉｄｅｌｉｎｋインターフェースとも呼ばれる。それを図３に示す。
現在、無線通信システムのＤＲＸは、端末とネットワークとの間のＵｕインターフェースにのみ適用可能であり、直接通信インターフェースには、まだＤＲＸメカニズムがないため、直接通信インターフェースでは、電力を節約できない。したがって、直接通信インターフェースに省電力メカニズムを導入する必要があり、その可能な方式は、直接通信インターフェースにＤＲＸメカニズムを導入することであるが、現在、直接通信インターフェースにおいて、ＤＲＸを如何に実現するかについては、開示されている解決案が未だにない。
本開示は、上記問題に対して、不連続受信タイマ維持方法及び端末を提供する。
図４に示すように、本開示の実施例に係る不連続受信タイマ維持方法は、端末に適用されるものであり、
直接通信インターフェースに対し、第一ハイブリッド自動再送要求（ＨＡＲＱ）プロセスに対応する伝送タイプに応じて、第一ＨＡＲＱプロセスに対応するタイマを管理するステップ４１を含む。
説明すべきなのは、本開示の実施例で言及される端末とは、直接通信を行う直接通信端末を指し、当該第一ＨＡＲＱプロセスに対応するタイマとは、第一ＨＡＲＱプロセスのＨＡＲＱ関連タイマを指し、当該第一ＨＡＲＱプロセスとは、端末が直接通信インターフェースで通信するために使用されたあるＨＡＲＱプロセスを指す。
説明すべきなのは、当該伝送タイプは、主にユニキャスト、マルチキャスト及びブロードキャストを含み、異なる伝送タイプに対しては、端末の処理方式も異なり、次に、異なる伝送タイプの観点から本開示の実施例を以下のように具体的に説明する。
一、前記伝送タイプがブロードキャストの場合
この場合、ステップ４１の具体的な実現方式は、
端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持しないことである。
二、前記伝送タイプがマルチキャストの場合
この場合、ステップ４１の具体的な実現方式は、以下のうち、１つを含む。
Ａ１１、端末が第一ＨＡＲＱプロセスに対応するタイマを維持しないことであり、
つまり、端末としては、直接通信インターフェースのマルチキャストプロセスに対し、直接通信端末がＨＡＲＱ関連タイマを維持しない。
Ａ１２、前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持し、そうでなければ、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持しないことであり、
説明すべきなのは、本開示の実施例で言及される端末は、直接通信インターフェースでデータ送信を行う端末であってもよいし、直接通信インターフェースでデータ受信を行う端末であってもよく、具体的に、前記端末が前記第一ＨＡＲＱプロセスを利用して直接通信インターフェースでデータ送信を行う場合、この実現方式は、以下のうち、１つを具体的に採用して実現されてもよい。
Ａ１２１、端末が、物理層直接通信共有チャネル（ＰＳＳＣＨ）伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマ（ＨＡＲＱ ＲＴＴ ｔｉｍｅｒ）をスタートさせ、前記ＨＡＲＱ往復遅延タイマがタイムアウトする際に、前記端末が、少なくとも、前記第一ＨＡＲＱプロセスに対する他の端末からのＨＡＲＱフィードバックとしてＨＡＲＱ非確認（ＨＡＲＱ ＮＡＣＫ）フィードバックを１つ受信していれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマ（ＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒ）をスタートさせることであり、
つまり、直接通信端末は、ＰＳＳＣＨを送信した後（ＰＳＳＣＨが繰り返し伝送（ｒｅｐｅｔｉｔｉｏｎ）をサポートしていれば、１回目のｒｅｐｅｔｉｔｉｏｎの後）、プロセス関連のＨＡＲＱ ＲＴＴ ｔｉｍｅｒをスタートさせる。当該プロセスのＨＡＲＱ ＲＴＴ ｔｉｍｅｒがタイムアウトする前に、前記プロセスフィードバックに対する直接通信相手方からのＨＡＲＱ ＮＡＣＫを少なくとも１つ受信していれば、前記プロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
Ａ１２２、端末が、ＰＳＳＣＨ伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることであり、
つまり、直接通信端末は、ＰＳＳＣＨを送信した後（ＰＳＳＣＨがｒｅｐｅｔｉｔｉｏｎをサポートしていれば、１回目のｒｅｐｅｔｉｔｉｏｎの後）、プロセス関連のＨＡＲＱ ＲＴＴ ｔｉｍｅｒをスタートさせる。当該プロセスのＨＡＲＱ ＲＴＴ ｔｉｍｅｒがタイムアウトすると、前記プロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
具体的に、前記端末が前記第一ＨＡＲＱプロセスを利用して直接通信インターフェースでデータ受信を行う場合、この実現方式は、以下のうち、１つを具体的に採用して実現されてもよい。
Ａ１２３、端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱフィードバックがＨＡＲＱ非確認フィードバックであれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることであり、
つまり、ＨＡＲＱプロセスの物理層直接通信フィードバックチャネル（ＰＳＦＣＨ）伝送の後、前記プロセスに対応するＨＡＲＱ ＲＴＴ ｔｉｍｅｒをスタートさせ、ＰＳＦＣＨでフィードバックされたのがＨＡＲＱ ＮＡＣＫであれば、前記プロセスに対応するＨＡＲＱ ＲＴＴ ｔｉｍｅｒがタイムアウトした後、前記プロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
Ａ１２４、端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることであり、
つまり、ＨＡＲＱプロセスのＰＳＦＣＨ伝送の後、前記ＨＡＲＱプロセスに対応するＨＡＲＱ ＲＴＴ ｔｉｍｅｒをスタートさせ、前記プロセスに対応するＨＡＲＱ ＲＴＴ ｔｉｍｅｒがタイムアウトした後、常に前記プロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
さらに、Ａ１２４の後に、本開示の実施例に係る前記不連続受信タイマ維持方法は、
前記ＨＡＲＱ再送タイマのランニング中の第一プリセット時間（Ｔ）内に、前記第一ＨＡＲＱプロセスに対する再送スケジューリングを受信していなければ、端末が前記ＨＡＲＱ再送タイマのランニングを停止させることを更に含み、
ここで、前記第一プリセット時間（Ｔ）は、前記ＨＡＲＱ再送タイマのタイマ時間以下である。
具体的に、前記プロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒのランニング中の時間Ｔ内（Ｔ≦ＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒのタイマ時間）に、前記ＨＡＲＱプロセスに対する再送スケジューリングを受信していなければ、ＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒを停止させる。説明すべきなのは、これは、Ａ１２３に対する最適化であり、こうして、一部のＵＥがＨＡＲＱ ＮＡＣＫフィードバックを行ったことに起因して発送側がＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせ、ａｃｔｉｖｅ ｔｉｍｅに入って新しいスケジューリングが発生しているが、受信側端末によって受信されないことが回避される。
Ａ１３、端末が第一ＨＡＲＱプロセスに対応するタイマを維持することである。
説明すべきなのは、この場合、直接通信インターフェースのマルチキャストプロセスに対し、ＴＢがＨＡＲＱ ＡＣＫ／ＮＡＣＫフィードバックを必要とするものであるかどうかに関わらず、ＨＡＲＱ関連タイマを維持する必要があり、ただし、この場合、端末は、ＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒのみを維持し、具体的に、以下の通りである。
Ａ１３１、前記端末が前記第一ＨＡＲＱプロセスを利用して直接通信インターフェースでデータ送信を行う場合
この場合の具体的な実現方式は、
端末が、ＰＳＳＣＨ伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることである。
つまり、直接通信端末は、ＰＳＳＣＨを送信した後（ＰＳＳＣＨがｒｅｐｅｔｉｔｉｏｎをサポートしていれば、１回目のｒｅｐｅｔｉｔｉｏｎの後）、ＰＳＳＣＨに使用されるプロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
Ａ１３２、前記端末が前記第一ＨＡＲＱプロセスを利用して直接通信インターフェースでデータ受信を行う場合
この場合の具体的な実現方式は、
端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信した後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることである。
つまり、直接通信端末は、ＰＳＳＣＨを受信した後、プロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
三、前記伝送タイプがユニキャストの場合
この場合、ステップ４１の具体的な実現方式は、以下のうち、１つを含む。
Ｂ１１、端末が第一ＨＡＲＱプロセスに対応するタイマを維持しないことであり、
つまり、直接通信インターフェースのユニキャストプロセスに対し、直接通信端末は、ＨＡＲＱ関連タイマを維持しない。
Ｂ１２、前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持し、そうでなければ、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持しないことであり、
説明すべきなのは、本開示の実施例で言及される端末は、データ送信を行ってもよいし、データ受信を行ってもよく、具体的に、前記端末が前記第一ＨＡＲＱプロセスを利用して直接通信インターフェースでデータ送信を行う場合、この実現方式は、
端末が、ＰＳＳＣＨ伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記ＨＡＲＱ往復遅延タイマがタイムアウトする際に、前記端末が、前記第一ＨＡＲＱプロセスに対するユニキャスト通信相手方からのＨＡＲＱフィードバックとしてＨＡＲＱ非確認フィードバックを受信していれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせるような方式を具体的に採用して実現されてもよい。
つまり、直接通信端末は、ＰＳＳＣＨを送信した後（ＰＳＳＣＨがｒｅｐｅｔｉｔｉｏｎをサポートしていれば、１回目のｒｅｐｅｔｉｔｉｏｎの後）、プロセス関連のＨＡＲＱ ＲＴＴ ｔｉｍｅｒをスタートさせる。前記プロセスのＨＡＲＱ ＲＴＴ ｔｉｍｅｒがタイムアウトする前に、直接通信相手方からフィードバックされたＨＡＲＱ ＮＡＣＫを受信していれば、前記プロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
具体的に、前記端末が前記第一ＨＡＲＱプロセスを利用して直接通信インターフェースでデータ受信を行う場合、この実現方式は、
端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱフィードバックがＨＡＲＱ非確認フィードバックであれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせるような方式を具体的に採用して実現されてもよい。
つまり、ＨＡＲＱプロセスのＰＳＦＣＨ伝送の後、前記プロセスに対応するＨＡＲＱ ＲＴＴ ｔｉｍｅｒをスタートさせ、ＰＳＦＣＨでフィードバックされたのがＨＡＲＱ ＮＡＣＫであれば、前記プロセスに対応するＨＡＲＱ ＲＴＴ ｔｉｍｅｒがタイムアウトした後、前記ＨＡＲＱプロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
Ｂ１３、端末が第一ＨＡＲＱプロセスに対応するタイマを維持することであり、
説明すべきなのは、この場合、直接通信インターフェースのユニキャストプロセスに対し、ＴＢがＨＡＲＱ ＡＣＫ／ＮＡＣＫフィードバックを必要とするものであるかどうかに関わらず、ＨＡＲＱ関連タイマを維持する必要があり、ただし、この場合、端末は、ＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒのみを維持し、具体的に、以下の通りである。
Ｂ１３１、前記端末が前記第一ＨＡＲＱプロセスを利用して直接通信インターフェースでデータ送信を行う場合
この場合の具体的な実現方式は、
端末が、ＰＳＳＣＨ伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることである。
つまり、直接通信端末は、ＰＳＳＣＨを送信した後（ＰＳＳＣＨがｒｅｐｅｔｉｔｉｏｎをサポートしていれば、１回目のｒｅｐｅｔｉｔｉｏｎの後）、ＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
Ｂ１３２、前記端末が前記第一ＨＡＲＱプロセスを利用して直接通信インターフェースでデータ受信を行う場合
この場合の具体的な実現方式は、
端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信した後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることである。
つまり、直接通信端末は、ＰＳＳＣＨを受信した後、プロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
次に、本開示の実施例の具体的な応用場面について、例を挙げて以下のように説明する。
例１：マルチキャスト及びブロードキャストなら、ＨＡＲＱタイマを維持せず、ユニキャストなら、ＨＡＲＱタイマを維持する
ＵＥ１が直接通信インターフェースでユニキャスト、ブロードキャスト及びマルチキャストの通信を同時に行うと仮定する。ユニキャスト、マルチキャスト及びブロードキャストについては、同一ＨＡＲＱエンティティを使用し、前記ＨＡＲＱエンティティは、一連の並行プロセスを維持する。
直接通信インターフェースでデータ伝送を行う場合、先ず、ＨＡＲＱプロセスに対応する伝送タイプを判断し、次に、直接通信インターフェースのＨＡＲＱプロセスに対応する伝送タイプに応じて、ＨＡＲＱ関連タイマに対して該当する維持方式を使用する。
例えば、直接通信インターフェースに３つのプロセスＡ、Ｂ、Ｃがあると仮定する。プロセスに対してＤＲＸタイマの維持を行う場合、先ず、プロセスに対応する伝送タイプを判断する必要があり、ＨＡＲＱプロセスＡに対応する伝送タイプがブロードキャスト、ＨＡＲＱプロセスＢに対応する伝送タイプがマルチキャスト、ＨＡＲＱプロセスＣに対応する伝送タイプがユニキャストであると仮定する。すると、直接通信インターフェースにおいて、前記３つのプロセスに対しては、その伝送タイプに応じて、異なるＨＡＲＱ関連タイマの維持方式が使用される。ここで、前記ＨＡＲＱ関連タイマは、直接通信インターフェースの送信に関連するＨＡＲＱ ＲＴＴ ｔｉｍｅｒ及びＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒを含む。
Ｍ１１、ＨＡＲＱプロセスＡについて、その対応する伝送タイプがブロードキャストであるため、前記ＨＡＲＱプロセスＡに対しては、ＨＡＲＱ関連タイマを維持する必要がない。
Ｍ１２、ＨＡＲＱプロセスＢについて、その対応する伝送タイプがマルチキャストであるため、前記ＨＡＲＱプロセスＢに対応するＴＢに対しては、ＨＡＲＱ関連タイマを維持する必要もない。
Ｍ１３、ＨＡＲＱプロセスＣについて、その対応する伝送タイプがユニキャストであるため、前記ＨＡＲＱプロセスＣに対しては、ＨＡＲＱ関連タイマを維持する必要がある。具体的なＨＡＲＱ関連タイマの維持メカニズムは、以下の通りである。
Ｍ１３１、端末がデータ送信を行う場合、端末が関連ＨＡＲＱプロセスに対応するタイマ維持を行う手順は、以下の通りである。
直接通信端末は、ＰＳＳＣＨを送信した後（ＰＳＳＣＨがｒｅｐｅｔｉｔｉｏｎをサポートしていれば、１回目のｒｅｐｅｔｉｔｉｏｎの後）、プロセス関連のＨＡＲＱ ＲＴＴ ｔｉｍｅｒをスタートさせる。前記プロセスのＨＡＲＱ ＲＴＴ ｔｉｍｅｒがタイムアウトする前に、直接通信相手方からフィードバックされたＨＡＲＱ ＮＡＣＫを受信していれば、前記プロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
Ｍ１３２、端末がデータ受信を行う場合、端末が関連ＨＡＲＱプロセスに対応するタイマ維持を行う手順は、以下の通りである。
ＨＡＲＱプロセスのＰＳＦＣＨ伝送の後、前記プロセスに対応するＨＡＲＱ ＲＴＴ ｔｉｍｅｒをスタートさせ、ＰＳＦＣＨでフィードバックされたのがＨＡＲＱ ＮＡＣＫであれば、前記プロセスに対応するＨＡＲＱ ＲＴＴ ｔｉｍｅｒがタイムアウトした後、前記ＨＡＲＱプロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
例２：ブロードキャストなら、ＨＡＲＱタイマを維持せず、マルチキャスト及びユニキャストなら、ＨＡＲＱタイマを維持する
ＵＥ１が直接通信インターフェースでユニキャスト、ブロードキャスト及びマルチキャストの通信を同時に行うと仮定する。ユニキャスト、マルチキャスト及びブロードキャストについては、同一ＨＡＲＱエンティティを使用し、前記ＨＡＲＱエンティティは、一連の並行プロセスを維持する。
直接通信インターフェースでデータ伝送を行う場合、先ず、ＨＡＲＱプロセスに対応する伝送タイプを判断し、次に、直接通信インターフェースのＨＡＲＱプロセスに対応する伝送タイプに応じて、ＨＡＲＱ関連タイマに対して該当する維持方式を使用する。
一例として、直接通信インターフェースに３つのプロセスＡ、Ｂ、Ｃがあると仮定する。プロセスに対してＤＲＸタイマの維持を行う場合、先ず、プロセスに対応する伝送タイプを判断する必要があり、ＨＡＲＱプロセスＡに対応する伝送タイプがブロードキャスト、ＨＡＲＱプロセスＢに対応する伝送タイプがマルチキャスト、ＨＡＲＱプロセスＣに対応する伝送タイプがユニキャストであると仮定する。すると、直接通信インターフェースにおいて、前記３つのプロセスに対しては、その伝送タイプに応じて、異なるＨＡＲＱ関連タイマの維持方式が使用される。ここで、前記ＨＡＲＱ関連タイマは、直接通信インターフェースの送信に関連するＨＡＲＱ ＲＴＴ ｔｉｍｅｒ及びＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒを含む。
Ｍ２１、ＨＡＲＱプロセスＡについて、その対応する伝送タイプがブロードキャストであるため、前記ＨＡＲＱプロセスＡに対しては、ＨＡＲＱ関連タイマを維持する必要がない。
Ｍ２２、ＨＡＲＱプロセスＢについて、その対応する伝送タイプがマルチキャストであるため、前記ＨＡＲＱプロセスに対応するＴＢに対しては、ＨＡＲＱ関連タイマを維持する必要があり、具体的なタイマ維持メカニズムは、以下のようにされてもよい。
Ｍ２２１、端末がデータ送信を行う場合、端末が関連ＨＡＲＱプロセスに対応するタイマ維持を行う手順は、以下の通りである。
直接通信端末は、ＰＳＳＣＨを送信した後（ＰＳＳＣＨがｒｅｐｅｔｉｔｉｏｎをサポートしていれば、１回目のｒｅｐｅｔｉｔｉｏｎの後）、プロセス関連のＨＡＲＱ ＲＴＴ ｔｉｍｅｒをスタートさせる。前記プロセスのＨＡＲＱ ＲＴＴ ｔｉｍｅｒがタイムアウトする前に、前記プロセスフィードバックに対する直接通信相手方からのＨＡＲＱ ＮＡＣＫを少なくとも１つ受信していれば、前記プロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
Ｍ２２２、端末がデータ受信を行う場合、端末が関連ＨＡＲＱプロセスに対応するタイマ維持を行う手順は、以下の方式ａ）又は方式ｂ）を採用してもよい。
方式ａ）、ＨＡＲＱプロセスのＰＳＦＣＨ伝送の後、前記プロセスに対応するＨＡＲＱ ＲＴＴ ｔｉｍｅｒをスタートさせ、ＰＳＦＣＨでフィードバックされたのがＨＡＲＱ ＮＡＣＫであれば、前記プロセスに対応するＨＡＲＱ ＲＴＴ ｔｉｍｅｒがタイムアウトした後、前記プロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
方式ｂ）、ＨＡＲＱプロセスのＰＳＦＣＨ伝送の後、前記ＨＡＲＱプロセスに対応するＨＡＲＱ ＲＴＴ ｔｉｍｅｒをスタートさせ、前記プロセスに対応するＨＡＲＱ ＲＴＴ ｔｉｍｅｒがタイムアウトした後、常に前記プロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。さらに、前記対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒのランニング中の時間Ｔ内（Ｔ≦ＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒの長さ）に、前記ＨＡＲＱプロセスに対する再送スケジューリングを受信していなければ、ＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒを停止させる。（注：これは、方式ａ）に対する最適化であり、こうして、一部のＵＥがＨＡＲＱ ＮＡＣＫフィードバックを行ったことに起因して発送側がＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせ、ａｃｔｉｖｅ ｔｉｍｅに入って新しいスケジューリングが発生しているが、受信側端末によって受信されないことが回避される）。
Ｍ２３、ＨＡＲＱプロセスＣについて、その対応する伝送タイプがユニキャストであるため、前記プロセスＣに対しては、ＨＡＲＱ関連タイマを維持する必要がある。具体的なＨＡＲＱ関連タイマの維持メカニズムは、以下の通りである。
Ｍ２３１、端末がデータ送信を行う場合、端末が関連ＨＡＲＱプロセスに対応するタイマ維持を行う手順は、以下の通りである。
直接通信端末は、ＰＳＳＣＨを送信した後（ＰＳＳＣＨがｒｅｐｅｔｉｔｉｏｎをサポートしていれば、１回目のｒｅｐｅｔｉｔｉｏｎの後）、プロセス関連のＨＡＲＱ ＲＴＴ ｔｉｍｅｒをスタートさせる。前記プロセスのＨＡＲＱ ＲＴＴ ｔｉｍｅｒがタイムアウトする前に、直接通信相手方からフィードバックされたＨＡＲＱ ＮＡＣＫを受信していれば、前記プロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
Ｍ２３１、端末がデータ受信を行う場合、端末が関連ＨＡＲＱプロセスに対応するタイマ維持を行う手順は、以下の通りである。
ＨＡＲＱプロセスのＰＳＦＣＨ伝送の後、前記プロセスに対応するＨＡＲＱ ＲＴＴ ｔｉｍｅｒをスタートさせ、ＰＳＦＣＨでフィードバックされたのがＨＡＲＱ ＮＡＣＫであれば、前記プロセスに対応するＨＡＲＱ ＲＴＴ ｔｉｍｅｒがタイムアウトした後、前記ＨＡＲＱプロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
例３：ブロードキャストなら、ＨＡＲＱタイマを維持せず、マルチキャスト及びユニキャストなら、ＨＡＲＱタイマを維持する
ＵＥ１が直接通信インターフェースでユニキャスト、ブロードキャスト及びマルチキャストの通信を同時に行うと仮定する。ユニキャスト、マルチキャスト及びブロードキャストについては、同一ＨＡＲＱエンティティを使用し、前記ＨＡＲＱエンティティは、一連の並行プロセスを維持する。
直接通信インターフェースでデータ伝送を行う場合、先ず、ＨＡＲＱプロセスに対応する伝送タイプを判断し、次に、直接通信インターフェースのＨＡＲＱプロセスに対応する伝送タイプに応じて、ＨＡＲＱ関連タイマに対して該当する維持方式を使用する。
一例として、直接通信インターフェースに３つのプロセスＡ、Ｂ、Ｃがあると仮定する。プロセスに対してＤＲＸタイマの維持を行う場合、先ず、プロセスに対応する伝送タイプを判断する必要があり、ＨＡＲＱプロセスＡに対応する伝送タイプがブロードキャスト、ＨＡＲＱプロセスＢに対応する伝送タイプがマルチキャスト、ＨＡＲＱプロセスＣに対応する伝送タイプがユニキャストであると仮定する。すると、直接通信インターフェースにおいて、前記３つのプロセスに対しては、その伝送タイプに応じて、異なるＨＡＲＱ関連タイマの維持方式が使用される。ここで、前記ＨＡＲＱ関連タイマは、直接通信インターフェースの送信に関連するＨＡＲＱ ＲＴＴ ｔｉｍｅｒ及びＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒを含む。
Ｍ３１、ＨＡＲＱプロセスＡについて、その対応する伝送タイプがブロードキャストであるため、前記ＨＡＲＱプロセスＡに対しては、ＨＡＲＱ関連タイマを維持する必要がない。
Ｍ３２、ＨＡＲＱプロセスＢについて、その対応する伝送タイプがマルチキャストであるため、前記ＨＡＲＱプロセスＴＢに対しては、維持ＨＡＲＱ関連タイマ、具体的なタイマ維持メカニズムは、以下のようにされてもよい。
Ｍ３２１、端末がデータ送信を行う場合、端末が関連ＨＡＲＱプロセスに対応するタイマ維持を行う手順は、以下の通りである。
直接通信端末は、ＰＳＳＣＨを送信した後（ＰＳＳＣＨがｒｅｐｅｔｉｔｉｏｎをサポートしていれば、１回目のｒｅｐｅｔｉｔｉｏｎの後）、プロセス関連のＨＡＲＱ ＲＴＴ ｔｉｍｅｒをスタートさせる。前記プロセスのＨＡＲＱ ＲＴＴ ｔｉｍｅｒがタイムアウトすると、前記プロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
Ｍ３２２、端末がデータ受信を行う場合、端末が関連ＨＡＲＱプロセスに対応するタイマ維持を行う手順は、以下の通りである。
ＨＡＲＱプロセスのＰＳＦＣＨ伝送の後、前記ＨＡＲＱプロセスに対応するＨＡＲＱ ＲＴＴ ｔｉｍｅｒをスタートさせ、前記プロセスに対応するＨＡＲＱ ＲＴＴ ｔｉｍｅｒがタイムアウトした後、常に前記プロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。さらに、前記対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒのランニング中の時間Ｔ内（Ｔ≦ＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒの長さ）に、前記ＨＡＲＱプロセスに対する再送スケジューリングを受信していなければ、ＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒを停止させる。
Ｍ３３、ＨＡＲＱプロセスＣについて、その対応する伝送タイプがユニキャストであるため、前記プロセスＣに対しては、ＨＡＲＱ関連タイマを維持する必要がある。具体的なＨＡＲＱ関連タイマの維持メカニズムは、以下の通りである。
Ｍ３３１、端末がデータ送信を行う場合、端末が関連ＨＡＲＱプロセスに対応するタイマ維持を行う手順は、以下の通りである。
直接通信端末は、ＰＳＳＣＨを送信した後（ＰＵＳＳＣＨがｒｅｐｅｔｉｔｉｏｎをサポートしていれば、１回目のｒｅｐｅｔｉｔｉｏｎの後）、プロセス（プロセスＣと記す）関連のＨＡＲＱ ＲＴＴ ｔｉｍｅｒをスタートさせる。前記プロセスＣのＨＡＲＱ ＲＴＴ ｔｉｍｅｒがタイムアウトする前に、直接通信の受信側端末からフィードバックされたＨＡＲＱ ＮＡＣＫを１つ受信していれば、プロセスＣに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
Ｍ３３２、端末がデータ受信を行う場合、端末が関連ＨＡＲＱプロセスに対応するタイマ維持を行う手順は、以下の通りである。
ＨＡＲＱプロセスＣのＰＳＦＣＨ伝送の後、プロセスＣに対応するＨＡＲＱ ＲＴＴ ｔｉｍｅｒをスタートさせ、ＰＳＦＣＨでフィードバックされたのがＨＡＲＱ ＮＡＣＫであれば、プロセスＣに対応するＨＡＲＱ ＲＴＴ ｔｉｍｅｒがタイムアウトした後、プロセスＣに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
例４：ブロードキャストなら、ＨＡＲＱタイマを維持せず、マルチキャスト及びユニキャストなら、ＨＡＲＱタイマを維持する
ＵＥ１が直接通信インターフェースでユニキャスト、ブロードキャスト及びマルチキャストの通信を同時に行うと仮定する。ユニキャスト、マルチキャスト及びブロードキャストについては、同一ＨＡＲＱエンティティを使用し、前記ＨＡＲＱエンティティは、一連の並行プロセスを維持する。
直接通信インターフェースでデータ伝送を行う場合、先ず、ＨＡＲＱプロセスに対応する伝送タイプを判断し、次に、直接通信インターフェースのＨＡＲＱプロセスに対応する伝送タイプに応じて、ＨＡＲＱ関連タイマに対して該当する維持方式を使用する。
直接通信インターフェースでデータ伝送を行う場合、先ず、ＨＡＲＱプロセスに対応する伝送タイプを判断し、次に、直接通信インターフェースのＨＡＲＱプロセスに対応する伝送タイプに応じて、ＨＡＲＱ関連タイマに対して該当する維持方式を使用する。
一例として、直接通信インターフェースに３つのプロセスＡ、Ｂ、Ｃがあると仮定する。プロセスに対してＤＲＸタイマの維持を行う場合、先ず、プロセスに対応する伝送タイプを判断する必要があり、ＨＡＲＱプロセスＡに対応する伝送タイプがブロードキャスト、ＨＡＲＱプロセスＢに対応する伝送タイプがマルチキャスト、ＨＡＲＱプロセスＣに対応する伝送タイプがユニキャストであると仮定する。すると、直接通信インターフェースにおいて、前記３つのプロセスに対しては、その伝送タイプに応じて、異なるＨＡＲＱ関連タイマの維持方式が使用される。ここで、前記ＨＡＲＱ関連タイマは、直接通信インターフェースの送信に関連するＨＡＲＱ ＲＴＴ ｔｉｍｅｒ及びＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒを含む。
Ｍ４１、ＨＡＲＱプロセスＡについて、その対応する伝送タイプがブロードキャストであるため、前記ＨＡＲＱプロセスＡに対しては、ＨＡＲＱ関連タイマを維持する必要がない。
Ｍ４２、ＨＡＲＱプロセスＢについて、その対応する伝送タイプがマルチキャストであるため、ＴＢがＨＡＲＱ ＡＣＫ／ＮＡＣＫフィードバックを必要とするものであるかどうかに関わらず、ＨＡＲＱ関連タイマを維持する必要がある。ただし、ＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒのみを維持し、具体的なタイマ維持メカニズムは、以下のようにされてもよい。
Ｍ４２１、端末がデータ送信を行う場合、端末が関連ＨＡＲＱプロセスに対応するタイマ維持を行う手順は、以下の通りである。
直接通信端末は、ＰＳＳＣＨを送信した後（ＰＳＳＣＨがｒｅｐｅｔｉｔｉｏｎをサポートしていれば、１回目のｒｅｐｅｔｉｔｉｏｎの後）、ＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
Ｍ４２２、端末がデータ受信を行う場合、端末が関連ＨＡＲＱプロセスに対応するタイマ維持を行う手順は、以下の通りである。
直接通信端末は、ＰＳＳＣＨを受信した後、前記プロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
Ｍ４３、ＨＡＲＱプロセスＣについて、その対応する伝送タイプがユニキャストであるため、前記プロセスＣに対しては、ＨＡＲＱ関連タイマを維持する必要がある。具体的なＨＡＲＱ関連タイマの維持メカニズムは、以下の通りである。
Ｍ４３１、端末がデータ送信を行う場合、端末が関連ＨＡＲＱプロセスに対応するタイマ維持を行う手順は、以下の通りである。
直接通信端末は、ＰＳＳＣＨを送信した後（ＰＳＳＣＨがｒｅｐｅｔｉｔｉｏｎをサポートしていれば、１回目のｒｅｐｅｔｉｔｉｏｎの後）、前記プロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
Ｍ４３２、端末がデータ送信を行う場合、端末が関連ＨＡＲＱプロセスに対応するタイマ維持を行う手順は、以下の通りである。
直接通信端末は、ＰＳＳＣＨを受信した後、プロセスに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。
説明すべきなのは、本開示の実施例によれば、直接通信インターフェースプロセスに関連するＤＲＸタイマの維持及びその維持方法の問題を解決でき、直接通信インターフェースのＤＲＸメカニズムを実現し、直接通信インターフェースの省電力を実現している。
図５に示すように、本開示の実施例は、端末であって、
直接通信インターフェースに対し、第一ハイブリッド自動再送要求（ＨＡＲＱ）プロセスに対応する伝送タイプに応じて、第一ＨＡＲＱプロセスに対応するタイマを管理するための管理モジュール５１を含む、端末５０を提供する。
選択的に、前記伝送タイプがブロードキャストの場合、前記管理モジュール５１は、
端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持しないことに用いられる。
選択的に、前記伝送タイプがマルチキャスト又はユニキャストの場合、前記管理モジュール５１は、
端末が第一ＨＡＲＱプロセスに対応するタイマを維持しないことと、
前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持し、そうでなければ、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持しないことと、
端末が第一ＨＡＲＱプロセスに対応するタイマを維持することとのうち、１つを実現するために用いられる。
さらに、前記伝送タイプがマルチキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ送信を行う場合、前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持する実現方式は、
端末が、物理層直接通信共有チャネル（ＰＳＳＣＨ）伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記ＨＡＲＱ往復遅延タイマがタイムアウトする際に、前記端末が、少なくとも、前記第一ＨＡＲＱプロセスに対する他の端末からのＨＡＲＱフィードバックとしてＨＡＲＱ非確認フィードバックを１つ受信していれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることと、
端末が、ＰＳＳＣＨ伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることとのうち、１つを含む。
さらに、前記伝送タイプがマルチキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ受信を行う場合、前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持する実現方式は、
端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱフィードバックがＨＡＲＱ非確認フィードバックであれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることと、
端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることとのうち、１つを含む。
さらに、上述の端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせる場合、前記端末は、
前記ＨＡＲＱ再送タイマのランニング中の第一プリセット時間Ｔ内に、前記第一ＨＡＲＱプロセスに対する再送スケジューリングを受信していなければ、端末が前記ＨＡＲＱ再送タイマのランニングを停止させるための停止モジュールを更に含み、
ここで、前記第一プリセット時間Ｔは、前記ＨＡＲＱ再送タイマのタイマ時間未満である。
さらに、前記伝送タイプがユニキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ送信を行う場合、前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持することは、
端末が、物理層直接通信共有チャネル（ＰＳＳＣＨ）伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記ＨＡＲＱ往復遅延タイマがタイムアウトする際に、前記端末が、前記第一ＨＡＲＱプロセスに対するユニキャスト通信相手方からのＨＡＲＱフィードバックとしてＨＡＲＱ非確認フィードバックを受信していれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることを実現する。
さらに、前記伝送タイプがユニキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ受信を行う場合、前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持することは、
端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱフィードバックがＨＡＲＱ非確認フィードバックであれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることを実現する。
さらに、前記端末が前記第一ＨＡＲＱプロセスを利用してデータ送信を行う場合、前記端末が第一ＨＡＲＱプロセスに対応するタイマを維持することは、
端末が、物理層直接通信共有チャネル（ＰＳＳＣＨ）伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることを実現する。
さらに、前記端末が前記第一ＨＡＲＱプロセスを利用してデータ受信を行う場合、前記端末が第一ＨＡＲＱプロセスに対応するタイマを維持することは、
端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信した後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることを実現する。
説明すべきなのは、当該端末の実施例は、上記方法の実施例に１対１で対応する端末であり、上記方法の実施例における全ての実現方式は、当該端末の実施例に適用可能で、同じ技術的効果を達成することもできる。
図６に示すように、本開示の実施例は、プロセッサ６１と、送受信機６２と、メモリ６３と、前記メモリ６３に記憶されて前記プロセッサ６１上で動作可能なプログラムとを含む端末であって、送受信機６２は、バスインターフェースを介してプロセッサ６１及びメモリ６３に接続されており、前記プロセッサ６１は、メモリ内のプログラムを読み取り、
直接通信インターフェースに対し、第一ハイブリッド自動再送要求（ＨＡＲＱ）プロセスに対応する伝送タイプに応じて、第一ＨＡＲＱプロセスに対応するタイマを管理する手順を実行するためのものである、端末６０を更に提供する。
説明すべきなのは、図６において、バスアーキテクチャは、任意数量の相互接続されたバス及びブリッジを含んでもよく、具体的には、プロセッサ６１を代表とした１つ又は複数のプロセッサと、メモリ６３を代表としたメモリとの各種回路が繋げられている。バスアーキテクチャは、周辺機器、電圧レギュレータや電力管理回路等の様々な他の回路を互いに繋げることも可能であるが、これらは、当分野において公知されているため、本明細書において、さらなる説明をしない。バスインターフェースは、インターフェースを提供するものである。送受信機６２は、複数の素子であってもよく、即ち送信機及び受信機を含んでもよく、伝送媒体にて様々な他の装置と通信するための手段を提供するものである。様々な端末に対して、ユーザインターフェース６４は、必要なデバイスを外部又は内部で接続可能なインターフェースであってもよく、接続されるデバイスは、小型キーボード、ディスプレイ、スピーカ、マイク、ジョイスティック等を含むが、これらに限定されない。プロセッサ６１は、バスアーキテクチャ及び一般的な処理の管理を担っており、メモリ６３は、プロセッサ６１の操作実行時に使用されるデータを記憶可能である。
選択的に、前記伝送タイプがブロードキャストの場合、前記プロセッサによって、前記第一ハイブリッド自動再送要求（ＨＡＲＱ）プロセスに対応する伝送タイプに応じて、第一ＨＡＲＱプロセスに対応するタイマを管理するプログラムが実行されると、
端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持しないステップが実現される。
選択的に、前記伝送タイプがマルチキャスト又はユニキャストの場合、前記プロセッサによって、前記第一ハイブリッド自動再送要求（ＨＡＲＱ）プロセスに対応する伝送タイプに応じて、第一ＨＡＲＱプロセスに対応するタイマを管理するプログラムが実行されると、
端末が第一ＨＡＲＱプロセスに対応するタイマを維持しないことと、
前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持し、そうでなければ、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持しないことと、
端末が第一ＨＡＲＱプロセスに対応するタイマを維持することとのうち、１つが実現される。
さらに、前記伝送タイプがマルチキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ送信を行う場合、前記プロセッサによって、上述の前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持するプログラムが実行されると、
端末が、物理層直接通信共有チャネル（ＰＳＳＣＨ）伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記ＨＡＲＱ往復遅延タイマがタイムアウトする際に、前記端末が、少なくとも、前記第一ＨＡＲＱプロセスに対する他の端末からのＨＡＲＱフィードバックとしてＨＡＲＱ非確認フィードバックを１つ受信していれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることと、
端末が、ＰＳＳＣＨ伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることとのうち、１つが実現される。
さらに、前記伝送タイプがマルチキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ受信を行う場合、前記プロセッサによって、上述の前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持するプログラムが実行されると、
端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱフィードバックがＨＡＲＱ非確認フィードバックであれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることと、
端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることとのうち、１つが実現される。
さらに、前記プロセッサによって、前記端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせるプログラムが実行された後、
前記ＨＡＲＱ再送タイマのランニング中の第一プリセット時間Ｔ内に、前記第一ＨＡＲＱプロセスに対する再送スケジューリングを受信していなければ、端末が前記ＨＡＲＱ再送タイマのランニングを停止させるステップを更に含み、
ここで、前記第一プリセット時間Ｔは、前記ＨＡＲＱ再送タイマのタイマ時間未満である。
さらに、前記伝送タイプがユニキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ送信を行う場合、前記プロセッサによって、上述の前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持するプログラムが実行されると、
端末が、物理層直接通信共有チャネル（ＰＳＳＣＨ）伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記ＨＡＲＱ往復遅延タイマがタイムアウトする際に、前記端末が、前記第一ＨＡＲＱプロセスに対するユニキャスト通信相手方からのＨＡＲＱフィードバックとしてＨＡＲＱ非確認フィードバックを受信していれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせるステップが実現される。
さらに、前記伝送タイプがユニキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ受信を行う場合、前記プロセッサによって、上述の前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持するプログラムが実行されると、
端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱフィードバックがＨＡＲＱ非確認フィードバックであれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせるステップが実現される。
さらに、前記端末が前記第一ＨＡＲＱプロセスを利用してデータ送信を行う場合、前記プロセッサによって、前記端末が第一ＨＡＲＱプロセスに対応するタイマを維持するプログラムが実行されると、
端末が、物理層直接通信共有チャネル（ＰＳＳＣＨ）伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせるステップが実現される。
さらに、前記端末が前記第一ＨＡＲＱプロセスを利用してデータ受信を行う場合、前記プロセッサによって、前記端末が第一ＨＡＲＱプロセスに対応するタイマを維持するプログラムが実行されると、
端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信した後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせるステップが実現される。
本開示の実施例は、コンピュータプログラムを記憶したコンピュータ読取可能な記憶媒体であって、前記コンピュータプログラムがプロセッサによって実行されると、端末に適用される不連続受信タイマ維持方法のステップが実現される、コンピュータ読取可能な記憶媒体を更に提供する。
なお、上記のネットワーク機器及び端末の各モジュールに対する分割は、論理機能での分割に過ぎず、実際に実現するとき、一部又は全てのモジュールは、１つの物理エンティティへ統合されてもよいし、物理的に分離されていてもよいことに理解されたい。そして、これらのモジュールは、全て処理要素によりソフトウェアを呼び出す形で実現されてもよいし、全てハードウェアにより実現されてもよく、また、一部のモジュールは、処理要素によりソフトウェアを呼び出す形で実現されるとともに、他の一部のモジュールは、ハードウェアにより実現されてもよい。例えば、確定モジュールは、独立して設けられた処理要素であってもよいし、上記装置のあるチップ内への統合により実現されてもよい。さらに、確定モジュールは、プログラムコードの形式で上記装置のメモリに記憶され、上記装置のある処理要素により呼び出されることで、上記確定モジュールの機能を実行してもよい。他のモジュールの実現は、確定モジュールと同様である。それに、これらのモジュールは、全て又は一部が統合されてもよいし、個別に実現されてもよい。本明細書に記載の処理要素は、信号の処理能力を有する集積回路であってもよい。実現するとき、上記方法の各ステップ又は上記各モジュールは、プロセッサ要素内のハードウェアの集積論理回路を用いることにより、又は、ソフトウェア形式のコマンドを用いることにより実装されてもよい。
例えば、各モジュールは、１つ又は複数の特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ、ＡＳＩＣ）、１つ又は複数のマイクロプロセッサ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ、ＤＳＰ）、若しくは、１つ又は複数のフィールドプログラマブルゲートアレイ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ、ＦＰＧＡ）など、上記方法を実施する１つ又は複数の集積回路として構成されてもよい。他の例として、上記のあるモジュールは、処理要素によりプログラムコードを呼び出す形で実現される場合、当該処理要素は、中央演算処理装置（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、ＣＰＵ）などの汎用プロセッサ、又は、プログラムコードを呼び出すことが可能な他のプロセッサであってもよい。さらなる例として、これらのモジュールは、一緒に統合されてもよいし、システムオンチップ（ｓｙｓｔｅｍ－ｏｎ－ａ－ｃｈｉｐ、ＳＯＣ）の形式で実現されてもよい。
本願の明細書及び特許請求の範囲における「第一」、「第二」などの用語は、類似しているオブジェクトを区別するために使用されるものであり、必ずしも特定の順序や前後順番を記述するために使用されるとは限らない。そのように使用されるデータは、適切な状況において互いに交換可能で、それによって、本明細書において記述される本願の実施例は、本明細書において図示又は記述される順序以外の順序で実施可能であることを理解されたい。また、用語「含む」及び「有する」、並びにそれらのあらゆる変体は、非排他的な包含をカバーするものであり、例えば、一連のステップやユニットを含む手順、方法、システム、製品や機器は、明示的に列挙されているこれらのステップやユニットのみを含むことに限定されず、明示的に列挙されていない他のステップやユニット、或いは、これらの手順、方法、製品や機器に固有の他のステップやユニットを含んでもよい。なお、明細書及び特許請求の範囲に使用される「及び／又は」とは、接続対象のうち、少なくとも１つを表すものであり、例えば、「Ａ及び／又はＢ及び／又はＣ」とは、Ａのみが存在する、Ｂのみが存在する、Ｃのみが存在する、及び、ＡとＢの両方が存在する、ＢとＣの両方が存在する、ＡとＣの両方が存在する、並びに、ＡとＢとＣの全てが存在するとの７つの場合を含む。同様に、本明細書及び特許請求の範囲に使用される「Ａ及びＢの少なくとも１つ」とは、「Ａのみが存在する、Ｂのみが存在する、又はＡとＢの両方が存在する」として理解されるべきである。
上述したのは、本開示の実施形態であり、注意すべきことは、当業者にとって、本開示に記載の原理を逸脱しない前提で、若干の改良及び潤色を更に行うことが可能であり、これらの改良及び潤色も本開示の保護範囲内であると見なされるべきである。
Ｍ１２、ＨＡＲＱプロセスＢについて、その対応する伝送タイプがマルチキャストであるため、前記ＨＡＲＱプロセスＢに対しては、ＨＡＲＱ関連タイマを維持する必要もない。
Ｍ２２、ＨＡＲＱプロセスＢについて、その対応する伝送タイプがマルチキャストであるため、前記ＨＡＲＱプロセスＢに対しては、ＨＡＲＱ関連タイマを維持する必要があり、具体的なタイマ維持メカニズムは、以下のようにされてもよい。
Ｍ３２、ＨＡＲＱプロセスＢについて、その対応する伝送タイプがマルチキャストであるため、前記ＨＡＲＱプロセスＢに対しては、維持ＨＡＲＱ関連タイマ、具体的なタイマ維持メカニズムは、以下のようにされてもよい。
Ｍ３３１、端末がデータ送信を行う場合、端末が関連ＨＡＲＱプロセスに対応するタイマ維持を行う手順は、以下の通りである。
直接通信端末は、ＰＳＳＣＨを送信した後（ＰＳＳＣＨがｒｅｐｅｔｉｔｉｏｎをサポートしていれば、１回目のｒｅｐｅｔｉｔｉｏｎの後）、プロセス（プロセスＣと記す）関連のＨＡＲＱ ＲＴＴ ｔｉｍｅｒをスタートさせる。前記プロセスＣのＨＡＲＱ ＲＴＴ ｔｉｍｅｒがタイムアウトする前に、直接通信の受信側端末からフィードバックされたＨＡＲＱ ＮＡＣＫを１つ受信していれば、プロセスＣに対応するＨＡＲＱ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅｒをスタートさせる。

Claims (24)

  1. 端末に適用される不連続受信タイマ維持方法であって、
    直接通信インターフェースに対し、第一ハイブリッド自動再送要求（ＨＡＲＱ）プロセスに対応する伝送タイプに応じて、第一ＨＡＲＱプロセスに対応するタイマを管理することを含む、不連続受信タイマ維持方法。
  2. 前記伝送タイプがブロードキャストの場合、前記の第一ハイブリッド自動再送要求（ＨＡＲＱ）プロセスに対応する伝送タイプに応じて、第一ＨＡＲＱプロセスに対応するタイマを管理することは、
    端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持しないことを含む、請求項１に記載の不連続受信タイマ維持方法。
  3. 前記伝送タイプがマルチキャスト又はユニキャストの場合、前記の第一ハイブリッド自動再送要求（ＨＡＲＱ）プロセスに対応する伝送タイプに応じて、第一ＨＡＲＱプロセスに対応するタイマを管理することは、
    端末が第一ＨＡＲＱプロセスに対応するタイマを維持しないことと、
    前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持し、そうでなければ、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持しないことと、
    端末が第一ＨＡＲＱプロセスに対応するタイマを維持することとのうち、１つを含む、請求項１に記載の不連続受信タイマ維持方法。
  4. 前記伝送タイプがマルチキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ送信を行う場合、前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持することは、
    端末が、物理層直接通信共有チャネル（ＰＳＳＣＨ）伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記ＨＡＲＱ往復遅延タイマがタイムアウトする際に、前記端末が、少なくとも、前記第一ＨＡＲＱプロセスに対する他の端末からのＨＡＲＱフィードバックとしてＨＡＲＱ非確認フィードバックを１つ受信していれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることと、
    端末が、ＰＳＳＣＨ伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることとのうち、１つを含む、請求項３に記載の不連続受信タイマ維持方法。
  5. 前記伝送タイプがマルチキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ受信を行う場合、前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持することは、
    端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱフィードバックがＨＡＲＱ非確認フィードバックであれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることと、
    端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることとのうち、１つを含む、請求項３に記載の不連続受信タイマ維持方法。
  6. 前記の端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせる場合、前記不連続受信タイマ維持方法は、
    前記ＨＡＲＱ再送タイマのランニング中の第一プリセット時間Ｔ内に、前記第一ＨＡＲＱプロセスに対する再送スケジューリングを受信していなければ、端末が前記ＨＡＲＱ再送タイマのランニングを停止させることを更に含み、
    ここで、前記第一プリセット時間Ｔは、前記ＨＡＲＱ再送タイマのタイマ時間未満である、請求項５に記載の不連続受信タイマ維持方法。
  7. 前記伝送タイプがユニキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ送信を行う場合、前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持することは、
    端末が、物理層直接通信共有チャネル（ＰＳＳＣＨ）伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記ＨＡＲＱ往復遅延タイマがタイムアウトする際に、前記端末が、前記第一ＨＡＲＱプロセスに対するユニキャスト通信相手方からのＨＡＲＱフィードバックとしてＨＡＲＱ非確認フィードバックを受信していれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることを含む、請求項３に記載の不連続受信タイマ維持方法。
  8. 前記伝送タイプがユニキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ受信を行う場合、前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持することは、
    端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱフィードバックがＨＡＲＱ非確認フィードバックであれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることを含む、請求項３に記載の不連続受信タイマ維持方法。
  9. 前記端末が前記第一ＨＡＲＱプロセスを利用してデータ送信を行う場合、前記端末が第一ＨＡＲＱプロセスに対応するタイマを維持することは、
    端末が、物理層直接通信共有チャネル（ＰＳＳＣＨ）伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることを含む、請求項３に記載の不連続受信タイマ維持方法。
  10. 前記端末が前記第一ＨＡＲＱプロセスを利用してデータ受信を行う場合、前記端末が第一ＨＡＲＱプロセスに対応するタイマを維持することは、
    端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信した後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることを含む、請求項３に記載の不連続受信タイマ維持方法。
  11. メモリと、プロセッサと、前記メモリに記憶されて前記プロセッサ上で動作可能なプログラムとを含む端末であって、前記プロセッサによって前記プログラムが実行されると、
    直接通信インターフェースに対し、第一ハイブリッド自動再送要求（ＨＡＲＱ）プロセスに対応する伝送タイプに応じて、第一ＨＡＲＱプロセスに対応するタイマを管理することが実現される。
  12. 前記伝送タイプがブロードキャストの場合、前記プロセッサによって、前記第一ハイブリッド自動再送要求（ＨＡＲＱ）プロセスに対応する伝送タイプに応じて、第一ＨＡＲＱプロセスに対応するタイマを管理するプログラムが実行されると、
    端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持しないことが実現される、請求項１１に記載の端末。
  13. 前記伝送タイプがマルチキャスト又はユニキャストの場合、前記プロセッサによって、前記第一ハイブリッド自動再送要求（ＨＡＲＱ）プロセスに対応する伝送タイプに応じて、第一ＨＡＲＱプロセスに対応するタイマを管理するプログラムが実行されると、
    端末が第一ＨＡＲＱプロセスに対応するタイマを維持しないことと、
    前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持し、そうでなければ、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持しないことと、
    端末が第一ＨＡＲＱプロセスに対応するタイマを維持することとのうち、１つが実現される、請求項１１に記載の端末。
  14. 前記伝送タイプがマルチキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ送信を行う場合、前記プロセッサによって、上述の前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持するプログラムが実行されると、
    端末が、物理層直接通信共有チャネル（ＰＳＳＣＨ）伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記ＨＡＲＱ往復遅延タイマがタイムアウトする際に、前記端末が、少なくとも、前記第一ＨＡＲＱプロセスに対する他の端末からのＨＡＲＱフィードバックとしてＨＡＲＱ非確認フィードバックを１つ受信していれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることと、
    端末が、ＰＳＳＣＨ伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることとのうち、１つが実現される、請求項１３に記載の端末。
  15. 前記伝送タイプがマルチキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ受信を行う場合、前記プロセッサによって、上述の前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持するプログラムが実行されると、
    端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱフィードバックがＨＡＲＱ非確認フィードバックであれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることと、
    端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることとのうち、１つが実現される、請求項１３に記載の端末。
  16. 前記プロセッサによって、前記端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせるプログラムが実行された後、
    前記ＨＡＲＱ再送タイマのランニング中の第一プリセット時間Ｔ内に、前記第一ＨＡＲＱプロセスに対する再送スケジューリングを受信していなければ、端末が前記ＨＡＲＱ再送タイマのランニングを停止させることが更に実現され、
    ここで、前記第一プリセット時間Ｔは、前記ＨＡＲＱ再送タイマのタイマ時間未満である、請求項１５に記載の端末。
  17. 前記伝送タイプがユニキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ送信を行う場合、前記プロセッサによって、上述の前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持するプログラムが実行されると、
    端末が、物理層直接通信共有チャネル（ＰＳＳＣＨ）伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記ＨＡＲＱ往復遅延タイマがタイムアウトする際に、前記端末が、前記第一ＨＡＲＱプロセスに対するユニキャスト通信相手方からのＨＡＲＱフィードバックとしてＨＡＲＱ非確認フィードバックを受信していれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることが実現される、請求項１３に記載の端末。
  18. 前記伝送タイプがユニキャストであり、且つ前記端末が前記第一ＨＡＲＱプロセスを利用してデータ受信を行う場合、前記プロセッサによって、上述の前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持するプログラムが実行されると、
    端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信してＨＡＲＱフィードバックを行った後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマをスタートさせ、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱフィードバックがＨＡＲＱ非確認フィードバックであれば、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ往復遅延タイマがタイムアウトした後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることが実現される、請求項１３に記載の端末。
  19. 前記端末が前記第一ＨＡＲＱプロセスを利用してデータ送信を行う場合、前記プロセッサによって、前記端末が第一ＨＡＲＱプロセスに対応するタイマを維持するプログラムが実行されると、
    端末が、物理層直接通信共有チャネル（ＰＳＳＣＨ）伝送を行った後、第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることが実現される、請求項１３に記載の端末。
  20. 前記端末が前記第一ＨＡＲＱプロセスを利用してデータ受信を行う場合、前記プロセッサによって、前記端末が第一ＨＡＲＱプロセスに対応するタイマを維持するプログラムが実行されると、
    端末が、第一ＨＡＲＱプロセスに付帯されているデータを受信した後、前記第一ＨＡＲＱプロセスに対応するＨＡＲＱ再送タイマをスタートさせることが実現される、請求項１３に記載の端末。
  21. コンピュータプログラムを記憶したコンピュータ読取可能な記憶媒体であって、前記コンピュータプログラムがプロセッサによって実行されると、請求項１～１０の何れか一項に記載の不連続受信タイマ維持方法が実現される、コンピュータ読取可能な記憶媒体。
  22. 端末であって、
    直接通信インターフェースに対し、第一ハイブリッド自動再送要求（ＨＡＲＱ）プロセスに対応する伝送タイプに応じて、第一ＨＡＲＱプロセスに対応するタイマを管理するための管理モジュールを含む、端末。
  23. 前記伝送タイプがブロードキャストの場合、前記管理モジュールは、
    端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持しないことに用いられる、請求項２２に記載の端末。
  24. 前記伝送タイプがマルチキャスト又はユニキャストの場合、前記管理モジュールは、
    端末が第一ＨＡＲＱプロセスに対応するタイマを維持しないことと、
    前記第一ＨＡＲＱプロセスに対応する伝送ブロック（ＴＢ）が、ＨＡＲＱフィードバックを行う必要のあるものであれば、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持し、そうでなければ、端末が前記第一ＨＡＲＱプロセスに対応するタイマを維持しないことと、
    端末が第一ＨＡＲＱプロセスに対応するタイマを維持することとのうち、１つを実現するために用いられる、請求項２２に記載の端末。
JP2022548681A 2020-02-10 2020-12-28 不連続受信タイマ維持方法及び端末 Active JP7420955B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN202010085289.7A CN113260024B (zh) 2020-02-10 2020-02-10 一种非连续接收定时器管理方法及终端
CN202010085289.7 2020-02-10
PCT/CN2020/139954 WO2021159870A1 (zh) 2020-02-10 2020-12-28 非连续接收定时器管理方法及终端

Publications (2)

Publication Number Publication Date
JP2023513585A true JP2023513585A (ja) 2023-03-31
JP7420955B2 JP7420955B2 (ja) 2024-01-23

Family

ID=77219429

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2022548681A Active JP7420955B2 (ja) 2020-02-10 2020-12-28 不連続受信タイマ維持方法及び端末

Country Status (6)

Country Link
US (1) US20230140680A1 (ja)
EP (1) EP4106484A4 (ja)
JP (1) JP7420955B2 (ja)
KR (1) KR20220137743A (ja)
CN (2) CN115314980A (ja)
WO (1) WO2021159870A1 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022061249A1 (en) * 2020-09-20 2022-03-24 Babaei Alireza Enhanced wireless device and wireless network processes
KR20230110599A (ko) * 2021-03-03 2023-07-24 엘지전자 주식회사 무선통신시스템에서 사이드링크에서 psfch 및 pucch 전송에 관련된 ue의 동작 방법
CN116017376A (zh) * 2021-10-21 2023-04-25 华为技术有限公司 一种通信方法、通信装置及通信系统
CN118104355A (zh) * 2021-12-02 2024-05-28 Oppo广东移动通信有限公司 一种drx定时器的运行方法及装置、终端设备
WO2023245594A1 (zh) * 2022-06-24 2023-12-28 Oppo广东移动通信有限公司 无线通信方法、终端设备以及网络设备
KR20240050275A (ko) * 2022-10-11 2024-04-18 아서스 테크놀러지 라이센싱 아이엔씨. 무선 통신 시스템에서 멀티캐스트 데이터 수신을 위한 DRX(Discontinuous Reception) 타이머 처리 방법 및 장치

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5307232B2 (ja) * 2008-05-07 2013-10-02 テレフオンアクチーボラゲット エル エム エリクソン（パブル） バッファ状態レポート（ｂｓｒ）の送信により起動される不連続受信（ｄｒｘ）タイマー
CN101635615B (zh) * 2008-07-25 2012-11-14 电信科学技术研究院 一种实现非连续接收方法和装置
KR101712302B1 (ko) * 2013-02-05 2017-03-03 애플 인크. 접속 모드 불연속 수신의 소비전력 감소
US20150098414A1 (en) * 2013-10-04 2015-04-09 Innovative Sonic Corporation Method and apparatus for supporting device-to-device (d2d) discovery in a wireless communication system
EP2961236A1 (en) * 2014-06-27 2015-12-30 Innovative Sonic Corporation Method and apparatus for cooperation between user equipment (ue) and serving cell in a wireless communication system
CN104579602A (zh) * 2014-12-25 2015-04-29 华中科技大学 一种lte中的广播组播重传方法
US11290863B2 (en) * 2016-07-21 2022-03-29 Samsung Electronics Co., Ltd. System and method for discovering user equipment (UE) over side link in device to device (D2D) communication
CN108307486A (zh) * 2016-08-11 2018-07-20 索尼公司 用于网络控制端和网络节点的电子设备和方法
CN108377177B (zh) * 2016-10-17 2021-03-02 华硕电脑股份有限公司 无线通信系统中处置不连续接收操作的方法和设备
CN108024320A (zh) * 2016-11-04 2018-05-11 华为技术有限公司 传输信息的方法、网络设备和终端设备
AU2016432553A1 (en) * 2016-12-16 2019-07-25 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Discontinuous reception method and device
CN108923894B (zh) * 2017-03-23 2023-04-18 中兴通讯股份有限公司 一种信息传输的方法、用户设备、基站、存储介质和系统
EP3739968B1 (en) * 2017-03-23 2022-05-04 Telefonaktiebolaget LM Ericsson (publ) Method and device for determining timer configuration
EP3529934B1 (en) * 2017-08-10 2021-09-29 Ofinno, LLC Harq retransmission and control channel monitoring
TWI678125B (zh) * 2017-09-28 2019-11-21 香港商鴻穎創新有限公司 控制新無線電之非連續接收的裝置及方法
CN110035502B (zh) * 2018-01-11 2021-06-08 华为技术有限公司 通信方法、通信设备和网络设备
CN110475391B (zh) * 2018-05-09 2021-10-26 大唐移动通信设备有限公司 非连续接收定时器的控制方法、装置、终端及基站
WO2020168458A1 (zh) * 2019-02-18 2020-08-27 北京小米移动软件有限公司 Drx定时器的运行方法、装置、设备及存储介质
CN110708145B (zh) * 2019-09-30 2021-11-30 展讯通信（上海）有限公司 Harq进程管理方法、装置、终端及存储介质
KR20210055489A (ko) * 2019-11-07 2021-05-17 삼성전자주식회사 무선 통신 시스템에서 v2x 통신을 수행하는 방법 및 장치
EP4074135A1 (en) * 2019-12-13 2022-10-19 Interdigital Patent Holdings, Inc. Nr sidelink discontinuous reception
CN113225846A (zh) * 2020-01-21 2021-08-06 华为技术有限公司 一种通信方法及装置
US11729843B2 (en) * 2020-01-21 2023-08-15 Asustek Computer Inc. Method and apparatus of handling device-to-device resource selection with consideration on discontinuous reception operation in a wireless communication system

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ASUSTEK: "The operation of UL HARQ RTT Timer for UL LAA", 3GPP TSG RAN WG2#96 R2-168444, JPN6023032032, 4 November 2016 (2016-11-04), FR, ISSN: 0005125629 *
HUAWEI, HISILICON: "Discussion on HARQ support for NR sidelink", 3GPP TSG RAN WG2#108 R2-1915968, JPN6023032031, 8 November 2019 (2019-11-08), FR, ISSN: 0005125628 *
LG ELECTRONICS: "New WID on NR sidelink enhancement", 3GPP TSG RAN#86 RP-193231, JPN6023032029, 12 December 2019 (2019-12-12), FR, ISSN: 0005125627 *

Also Published As

Publication number Publication date
EP4106484A1 (en) 2022-12-21
EP4106484A4 (en) 2023-08-09
CN113260024B (zh) 2022-08-26
US20230140680A1 (en) 2023-05-04
JP7420955B2 (ja) 2024-01-23
KR20220137743A (ko) 2022-10-12
WO2021159870A1 (zh) 2021-08-19
CN113260024A (zh) 2021-08-13
CN115314980A (zh) 2022-11-08

Similar Documents

Publication Publication Date Title
JP7420955B2 (ja) 不連続受信タイマ維持方法及び端末
CN108270536B (zh) 一种监听指示及监听方法、装置
WO2013020417A1 (zh) 一种非连续接收方法及系统
EP4376449A2 (en) Wireless communication method and communication apparatus
WO2020143730A1 (zh) 一种通信方法和通信装置
CN113260025B (zh) 一种非连续接收处理方法、终端、装置以及介质
US20220053596A1 (en) Discontinuous reception control method, device and storage medium
US20230389047A1 (en) Sidelink communication method and apparatus
WO2020243931A1 (zh) 调整pdcch监听周期的方法和设备
CN110769381B (zh) 一种drx实现和配置方法及装置
CN115209558A (zh) 一种侧行链路的传输方法及装置
WO2022206925A1 (zh) 一种侧行链路的传输方法及装置
US20230074206A1 (en) Communication method, apparatus, and system
WO2014205739A1 (zh) 数据接收方法、发送方法及设备
WO2022178813A1 (zh) 一种侧行链路通信方法及装置
KR20170003652A (ko) 데이터 스케줄링 방법 및 장치
WO2021155603A1 (zh) 基于drx的侧行反馈方法及相关装置
WO2021159868A1 (zh) 非连续接收处理方法、终端、装置以及介质
WO2021000681A1 (zh) 重复传输维护方法、终端及网络设备
WO2023274016A1 (zh) 信息传输方法、资源调度方法、装置、终端及网络侧设备
WO2022067733A1 (zh) 一种配置非连续接收drx参数的方法、设备和通信系统
WO2023274017A1 (zh) 配置方法、设备及计算机可读存储介质
WO2024092570A1 (zh) 一种非连续接收的实现方法及装置、终端设备
WO2022120582A1 (zh) 一种系统信息块传输方法及通信装置
JP2024507572A (ja) 車両インターネットにおける伝送リソースの選択方法、装置及び端末

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220818

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220818

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20230802

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230808

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20231102

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20231212

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240111

R150 Certificate of patent or registration of utility model

Ref document number: 7420955

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150