EP3858064A1 - Système et procédés permettant un edt dl - Google Patents

Système et procédés permettant un edt dl

Info

Publication number
EP3858064A1
EP3858064A1 EP19865907.0A EP19865907A EP3858064A1 EP 3858064 A1 EP3858064 A1 EP 3858064A1 EP 19865907 A EP19865907 A EP 19865907A EP 3858064 A1 EP3858064 A1 EP 3858064A1
Authority
EP
European Patent Office
Prior art keywords
edt
data
rrc
transmission
message
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.)
Withdrawn
Application number
EP19865907.0A
Other languages
German (de)
English (en)
Other versions
EP3858064A4 (fr
Inventor
Bharat Shrestha
Seau S. Lim
Marta MARTINEZ TARRADELL
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.)
Intel Corp
Original Assignee
Intel Corp
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 Intel Corp filed Critical Intel Corp
Publication of EP3858064A1 publication Critical patent/EP3858064A1/fr
Publication of EP3858064A4 publication Critical patent/EP3858064A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H04W74/08—Non-scheduled access, e.g. ALOHA
    • H04W74/0833—Random access procedures, e.g. with 4-step access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W68/00—User notification, e.g. alerting and paging, for incoming communication, change of service or the like
    • H04W68/005—Transmission of information for alerting of incoming communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/27—Transitions between radio resource control [RRC] states

Definitions

  • Embodiments pertain to radio access networks (RANs). Some embodiments relate to cellular networks, including Third Generation Partnership Project (3GPP) Long Term Evolution (LTE), 4 th generation (4G) and 5 th generation (5G) New Radio (NR) (or next generation (NG)) networks. Some embodiments relate to mobile-terminated (MT) early data transmission (EDT).
  • 3GPP Third Generation Partnership Project
  • LTE Long Term Evolution
  • 4G 4 th generation
  • 5G 5 th generation
  • NR New Radio
  • NG next generation
  • EDT mobile-terminated
  • UEs user equipment
  • network processes may include the security processes for UEs, and in particular security processes used during early data transmission (EDT).
  • EDT early data transmission
  • FIG. 1 illustrates combined communication system in accordance with some embodiments.
  • FIG. 2 illustrates a block diagram of a communication device in accordance with some embodiments.
  • FIG. 3 illustrates downlink (DL) EDT solution including S 1 AP signaling in accordance with some embodiments.
  • FIG. 4 illustrates use of direct indication information for MT
  • FIG. 5 illustrates details of MT EDT transmission in accordance with some embodiments.
  • FIG. 1 illustrates a combined communication system in accordance with some embodiments.
  • the system 100 includes 3GPP LTE/4G and NG network functions.
  • a network function can be implemented as a discrete network element on a dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., dedicated hardware or a cloud infrastructure.
  • the evolved packet core (EPC) of the LTE/4G network contains protocol and reference points defined for each entity.
  • These core network (CN) entities may include a mobility management entity (MME) 122, serving gateway (S-GW) 124, and paging gateway (P-GW) 126.
  • MME mobility management entity
  • S-GW serving gateway
  • P-GW paging gateway
  • the TIE 102 may be connected to either an access network or random access network (RAN) 110 and/or may be connected to the NG-RAN 130 (gNB) or an Access and Mobility Function (AMF) 142.
  • the RAN 110 may be an eNB or a general non-3GPP access point, such as that for Wi-Fi.
  • the NG core network may contain multiple network functions besides the AMF 112.
  • the UE 102 may generate, encode and perhaps encrypt uplink transmissions to, and decode (and decrypt) downlink transmissions from, the RAN 110 and/or gNB 130 (with the reverse being true by the RAN 1 lO/gNB 130).
  • the network functions may include a User Plane Function (UPF)
  • UPF User Plane Function
  • SMF Session Management Function
  • PCF Policy Control Function
  • AF Application Function
  • AUSF Authentication Server Function
  • UDM User Data Management
  • the AMF 142 may provide UE-based authentication, authorization, mobility management, etc.
  • the AMF 142 may be independent of the access technologies.
  • the SMF 144 may be responsible for session management and allocation of IP addresses to the UE 102.
  • the SMF 144 may also select and control the UPF 146 for data transfer.
  • the SMF 144 may be associated with a single session of the UE 102 or multiple sessions of the UE 102. This is to say that the UE 102 may have multiple 5G sessions. Different SMFs may be allocated to each session. The use of different SMFs may permit each session to be individually managed. As a consequence, the functionalities of each session may be independent of each other.
  • the UPF 126 may be connected with a data network, with which the UE 102 may communicate, the UE 102 transmitting uplink data to or receiving downlink data from the data network.
  • the AF 148 may provide information on the packet flow to the
  • the PCF 132 responsible for policy control to support a desired QoS.
  • the PCF 132 may set mobility and session management policies for the UE 102. To this end, the PCF 132 may use the packet flow information to determine the appropriate policies for proper operation of the AMF 142 and SMF 144.
  • the AUSF 152 may store data for UE authentication.
  • the UDM 128 may similarly store the UE subscription data.
  • the gNB l30 may be a standalone gNB or a non- standalone gNB, e.g., operating in Dual Connectivity (DC) mode as a booster controlled by the eNB 110 through an X2 or Xn interface. At least some of functionality of the EPC and the NG CN may be shared (alternatively, separate components may be used for each of the combined component shown).
  • the eNB 110 may be connected with an MME 122 of the EPC through an Sl interface and with a SGW 124 of the EPC 120 through an Sl-U interface.
  • the MME 122 may be connected with an HSS 128 through an S6a interface while the UDM is connected to the AMF 142 through the N8 interface.
  • the SGW 124 may connected with the PGW 126 through an S5 interface (control plane PGW-C through S5-C and user plane PGW-U through S5-U).
  • the PGW 126 may serve as an IP anchor for data through the internet.
  • the NG CN may contain an AMF 142, SMF 144 and
  • the eNB 110 and gNB 130 may communicate data with the SGW 124 of the EPC 120 and the UPF 146 of the NG CN.
  • the MME 122 and the AMF 142 may be connected via the N26 interface to provide control information there between, if the N26 interface is supported by the EPC 120.
  • the gNB 130 is a standalone gNB, the 5G CN and the EPC 120 may be connected via the N26 interface.
  • FIG. 2 illustrates a block diagram of a communication device in accordance with some embodiments.
  • the communication device may be a UE (including an IoT device and NB-IoT device), eNB, gNB or other equipment used in the network environment.
  • the UE including an IoT device and NB-IoT device
  • eNB evolved Node B
  • gNB gNode B
  • communication device 200 may be a specialized computer, a personal or laptop computer (PC), a tablet PC, a mobile telephone, a smart phone, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine.
  • PC personal or laptop computer
  • tablet PC a mobile telephone
  • smart phone a smart phone
  • network router switch or bridge
  • the communication device 200 may be embedded within other, non-communication-based devices such as vehicles and appliances.
  • Examples, as described herein, may include, or may operate on, logic or a number of components, modules, or mechanisms.
  • Modules and components are tangible entities (e.g., hardware) capable of performing specified operations and may be configured or arranged in a certain manner.
  • circuits may be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module.
  • the whole or part of one or more computer systems e.g., a standalone, client or server computer system
  • one or more hardware processors may be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations.
  • the software may reside on a machine readable medium.
  • the software when executed by the underlying hardware of the module, causes the hardware to perform the specified operations.
  • module (and“component”) is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein.
  • modules are temporarily configured, each of the modules need not be instantiated at any one moment in time.
  • the modules comprise a general-purpose hardware processor configured using software
  • the general-purpose hardware processor may be configured as respective different modules at different times.
  • Software may accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time.
  • the communication device 200 may include a hardware processor 202 (e.g., a central processing unit (CPU), a GPU, a hardware processor core, or any combination thereof), a main memory 204 and a static memory 206, some or all of which may communicate with each other via an interlink (e.g., bus) 208.
  • the main memory 204 may contain any or all of removable storage and non-removable storage, volatile memory or non-volatile memory.
  • the communication device 200 may further include a display unit 210 such as a video display, an alphanumeric input device 212 (e.g., a keyboard), and a user interface (UI) navigation device 214 (e.g., a mouse).
  • a hardware processor 202 e.g., a central processing unit (CPU), a GPU, a hardware processor core, or any combination thereof
  • main memory 204 may contain any or all of removable storage and non-removable storage, volatile memory or non-volatile memory.
  • the communication device 200 may further
  • the display unit 210, input device 212 and UI navigation device 214 may be a touch screen display.
  • the communication device 200 may additionally include a storage device (e.g., drive unit) 216, a signal generation device 218 (e.g., a speaker), a network interface device 220, and one or more sensors, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor.
  • GPS global positioning system
  • the communication device 200 may further include an output controller, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).
  • a serial e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).
  • USB universal serial bus
  • IR infrared
  • NFC near field communication
  • the storage device 216 may include a non-transitory machine readable medium 222 (hereinafter simply referred to as machine readable medium) on which is stored one or more sets of data structures or instructions 224 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein.
  • the instructions 224 may also reside, successfully or at least partially, within the main memory 204, within static memory 206, and/or within the hardware processor 202 during execution thereof by the communication device 200.
  • the machine readable medium 222 is illustrated as a single medium, the term "machine readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions 224.
  • machine readable medium may include any medium that is capable of storing, encoding, or carrying instructions for execution by the communication device 200 and that cause the communication device 200 to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions.
  • Non-limiting machine readable medium examples may include solid-state memories, and optical and magnetic media.
  • machine readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; Random Access Memory (RAM); and CD-ROM and DVD-ROM disks.
  • non-volatile memory such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices
  • EPROM Electrically Programmable Read-Only Memory
  • EEPROM Electrically Erasable Programmable Read-Only Memory
  • flash memory devices e.g., electrically Erasable Programmable Read-Only Memory (EEPROM)
  • EPROM Electrically Programmable Read-Only Memory
  • EEPROM Electrically Erasable Programmable Read-Only Memory
  • flash memory devices e.g
  • the instructions 224 may further be transmitted or received over a communications network using a transmission medium 226 via the network interface device 220 utilizing any one of a number of transfer protocols (e.g., frame relay, internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.).
  • Example communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, and wireless data networks. Communications over the networks may include one or more different protocols, such as Institute of Electrical and Electronics
  • Wi-Fi Wi-Fi
  • WiMax WiMax
  • IEEE 802.15.4 family of standards
  • LTE Long Term Evolution
  • the network interface device 220 may include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the transmission medium 226.
  • physical jacks e.g., Ethernet, coaxial, or phone jacks
  • antennas to connect to the transmission medium 226.
  • the communication device 200 may be an IoT device (also referred to as a“Machine-Type Communication device” or“MTC device”), a narrowband IoT (NB-IoT) device, or a non-IoT device (e.g., smart phone, vehicular UE), any which may communicate with the core network via the eNB or gNB shown in FIG. 1.
  • the communication device 200 may be an IoT device (also referred to as a“Machine-Type Communication device” or“MTC device”), a narrowband IoT (NB-IoT) device, or a non-IoT device (e.g., smart phone, vehicular UE), any which may communicate with the core network via the eNB or gNB shown in FIG. 1.
  • the communication device 200 may be an IoT device (also referred to as a“Machine-Type Communication device” or“MTC device”), a narrowband IoT (NB-IoT) device, or a non-Io
  • the communication device 200 is IoT device, in some embodiments, the
  • the communication device 200 may be limited in memory, size, or functionality, allowing larger numbers to be deployed for a similar cost to smaller numbers of larger devices.
  • the communication device 200 may, in some embodiments, be a virtual device, such as an application on a smart phone or other computing device.
  • RRC messages are provided over the course of the connection between the UE and an eNB.
  • RRC messages include initial connection messages, such as RRC connection request, RRC connection setup and RRC connection setup, reconfiguration messages, such as RRC connection reconfiguration and RRC connection reconfiguration complete messages, and suspension and release messages, such as RRC Connection Release and RRC Connection Reestablish/Resume messages.
  • initial connection messages such as RRC connection request, RRC connection setup and RRC connection setup
  • reconfiguration messages such as RRC connection reconfiguration and RRC connection reconfiguration complete messages
  • suspension and release messages such as RRC Connection Release and RRC Connection Reestablish/Resume messages.
  • EDT may be used.
  • EDT allows one uplink data transmission, optionally followed by one downlink data transmission during the random access procedure.
  • EDT is triggered when the upper layers have requested the establishment or resumption of the RRC Connection for Mobile Originated (MO) data and the uplink data size is less than or equal to a transport block size indicated in the system information.
  • MO Mobile Originated
  • the EE may send a preamble (Msgl) over a Physical Random Access Channel (PRACH) transmission to the eNB to start a random access channel (RACH) procedure.
  • the preamble may indicate the intent of the EE to use EDT.
  • the RACH request may be transmitted by the EE to the eNB using a RACH resource.
  • the RACH request may be transmitted over 6 Resource blocks.
  • the RACH request may contain a preamble index, which may be randomly selected based on the size of the RRC connection request from preamble information in system information block (SIB).
  • SIB system information block
  • the RACH Request for EDT may use a unique preamble that is different from that used for a legacy procedure.
  • the eNB having received the RACH request may allocate a temporary Cell Radio Network Temporary Identifier (C-RNTI) for the EE.
  • C-RNTI Cell Radio Network Temporary Identifier
  • the temporary Cell RNTI may be transmitted to the EE in a RACH Response message (RAR) (Msg2) from the RAN.
  • RAR message may also contain the appropriate timing advance (TA) for the EE, determined by the eNB.
  • the RAR message may contain a scheduling grant for the EE to send a
  • RRCConnectionResumeRequest message where the scheduling grant may indicate whether frequency hopping is to be used as well as the resource block assignment.
  • the RAR message may further indicate the modulation and coding scheme and the power for the PUSCH to be used by the EE. If EDT is to be used, the UL grant in the RAR message may be larger than that of a legacy RAR grant to provide additional UL resources for transmission by the UE of a UL message in addition to a RRCConnectionResumeRequest message.
  • the UE may transmit a RRCConnectionResumeRequest message including a shortResumeMAC-I .
  • the UE may also multiplex the UL UP data with the RRC message to transmit in Msg3.
  • Msg3 may use a SAE-Temporary Mobile Subscriber Identity (S-TMSI).
  • the eNB may in response transmit an RRC Connection Setup message (Msg4) to the UE.
  • Msg4 RRC Connection Setup message
  • the UE may not transition from the RRC Idle state to the RRC Connected state during EDT.
  • a capability indication for mobile terminated (MT) EDT which may be used to transmit a small amount of DL data in Msg4 without a small amount of UL data being transmitted in Msg3, is not defined.
  • the MME or eNB may not know if the UE will be ready to receive DL data in Msg4, for example, sending NAS service request in Msg3 in control plane (CP) solutions or activating AS security before Msg3 in a user plane (UP) solution.
  • the UE may not be aware on receiving a paging message that the MME has MT EDT data.
  • the various embodiments here describe UEs and network capability indication to decide to use DL (MT) EDT in Msg4.
  • the MME may locate the UE to which the data is to be delivered. To this end, the MME may page the UE and receive a service request from the UE. Only an S-TMSI received from the RRC connection request message in Msg3 may not be sufficient from security point of view as the S- TMSI may have been exposed.
  • the UE may send a NAS PDU (service request) with or without a data container in Msg3. This, in turn, may cause the UE to request a larger UL grant in the RAR than the minimum UL grant (56 bits).
  • the eNB may make sure that the UE has already activated AS security before the eNB can send the encrypted MT data in Msg4.
  • small DL data may be transmitted in Msg4.
  • the network may use the DL EDT solution.
  • the eNB can decide whether the UE should be moved back to IDLE or RRC CONNECTED mode using Msg4.
  • UL EDT it may be possible that acknowledgment for the UL EDT data can be sent in Msg4.
  • the UE may send Msg5 if acknowledgement of DL EDT data in Msg4 is to be sent.
  • the network may ask the UE to move to the RRC CONNECTED mode. After receiving Msg5, the network may send an RRCConnectionRelease message in Msg6 to move the UE to the IDLE mode if the indicated buffer status report (BSR) is zero. Therefore, the Rel-l6 DL EDT can be used to send the small DL data whether or not the acknowledgement is to be sent.
  • BSR buffer status report
  • DL-EDT may accordingly be defined as: if an acknowledgement of DL data in Msg4 is not to be sent, the network may move the UE to the IDLE mode using Msg4. Otherwise, the network may move the UE to the
  • the network may release the UE to the IDLE mode using Msg6.
  • the MME is unaware of DL EDT.
  • the MME may provide DL data size information, UE-RadioPaginglnfo (whether UE or not supports DL- EDT), whether or not the UE is to provide acknowledgment and Sl AP paging to the eNB.
  • the MME is unaware of DL EDT.
  • the MME may send Sl AP paging and indication of a single DL data to the eNB. The remainder may be handled by the eNB without knowing whether or not the DL data can fit in a single TB for transmission.
  • the MME is aware of DL EDT.
  • the MME may receive DL EDT support capability from Msg5.
  • the MME may also define the maximum TBS size limit to be used for DL-EDT.
  • the MME may decide whether to inform the eNB that DL-EDT can or cannot be used (when sending paging) based on the UE’s capability, DL data size and whether or not the EGE is to provide acknowledgment.
  • the MME is aware of DL EDT.
  • the MME may only store the
  • EIE DL EDT capability. Based on the capability, and whether or not the UE is to provide acknowledgment when there is DL data, the MME may send Sl AP paging including a DL-EDT indication and size of DL data to the eNB.
  • the MME is aware of DL EDT.
  • the MME may only store the
  • the MME may send legacy Sl AP paging and a single DL data indication.
  • the eNB may decide whether or not to use DL EDT (based on channel condition and data size). The eNB can assume that the UE is able to not to provide
  • FIG. 3 illustrates DL EDT solution including Sl AP signaling in accordance with some embodiments. If the UE is using CP cellular internet of things (CloT) optimization and the network wants the UE to move to the RRC CONNECTED mode, the network may send an
  • RRCConnectionSetupRequest message in Msg4.
  • a new RRC Connection Setup message may be defined to deliver the CP data using dedicatedlnfoNAS in Msg4 (from the serving eNB (SeNB)) that moves the UE to the RRC CONNECTED mode.
  • SeNB serving eNB
  • An example using the extension field is shown below.
  • RRCConnectionSetup The RRCConnectionSetup message is used to establish SRB1.
  • Signalling radio bearer SRB0.
  • RLC-SAP TM.
  • Logical channel CCCH.
  • Direction E-UTRAN to UE.
  • RRCConnectionSetup The RRCConnectionSetup message is used to establish SRB1.
  • Signalling radio bearer SRB0.
  • RLC-SAP TM.
  • Logical channel CCCH.
  • Direction E-UTRAN to UE.
  • the paging message may contain the indication.
  • the paging message may contain a DL-EDT indication or PRACH resource indication.
  • a few bits in the paging message may be used to indicate the index of the preamble to use from a preconfigured pool of dedicated PRACH resources.
  • the pool of dedicated PRACH resources can be broadcast in system information or configured using dedicated RRC signaling differently for each UE. This pool can also be shared with a Rel-l5 EDT PRACH resource or legacy PRACH resource.
  • the size of the pool of the PRACH resource can be one or larger than one for each coverage enhancement level.
  • the pool of PRACH resources can contain only a random access preamble and time and frequency PRACH resource can be same as legacy or Rel-l5 EIL EDT.
  • CE enhancement enhancement
  • the eNB may page the EIEs at different paging occasions.
  • all EIEs having DL-EDT data are paged together but each LIE in the paging record list, PagingRecordList, may delay sending the RA preamble by not using the first kth PRACH resource, where k is equal to index number of the UE in the PagingRecordList.
  • the UE may delay the generation of the RRC message in response to the paging message by K time units to minimize a possible collision with the paged UE.
  • all UEs use the same preamble but use a different time/frequency PRACH resource as indicated by a PRACH mask index value as specified in TS 36.321 section 7.3.
  • the PRACH mask index value may be determined from the index value in the PagingRecordList.
  • preamble group A and B may be used.
  • Rel-l6 DL EDT preamble group B may be used to indicate the UE capability or that the UE is ready to receive DL-EDT in Msg4.
  • preamble group A can be used for Rel-l5 UL EDT. This may indicate that the UE has prepared an RRC message including a NAS service request to send in Msg3 for a CP solution. The UE may activate AS security before transmission of Msg3 in the UP solution.
  • the CE level can be indicated from the time and frequency PRACH resource as a separate dedicated PRACH resource or may use the same resource as the Rel-l5 UL EDT PRACH resource or the PRACH resource for CE.
  • some of the Rel-l5 UL EDT preambles (say n preambles, where n > 0) can be allocated to use for Rel-l6 DL EDT for each configured CE level.
  • the UE may not use the dedicated DL-EDT PRACH resource even if the DL-EDT indication is received in the paging message.
  • a dedicated PRACH for DL EDT may be used only when the UE is using CP CloT optimization.
  • UEs using UP CloT optimization may use the legacy PRACH resource for each CE level.
  • the maximum TBS size that can be transmitted using the UL EDT solution is 1000 bits for CE mode A and 936 bits in CE mode B.
  • the maximum TBS size can be determined by the network depending on the UE category and channel condition since the resource for the Msg4 is dynamically scheduled.
  • the eNB may not know beforehand the UE’s CE level until the eNB receives Msgl and the UE’s category (for support of larger TBS size) until context is fetched.
  • the eNB may know in the indication from the MME that the size of available small DL data is 1000 bits for a UE, but may not know whether the UE’s CE level is 0/1 or 2/3.
  • the received preamble corresponds to CE level 2 or 3
  • the small data 1000 bits
  • the UE may always have to be prepared as the UE may fall back to the legacy procedure after sending the Msg3 for DL EDT.
  • the MME may also provide the size of the small data along with an Sl AP paging message to the eNB. This may indicate to the eNB to decide whether or not the DL-EDT should be used based on the UE’s category, the UE’s DL-EDT capability or the channel condition, and the UE’s support for scheduling of multiple transport blocks or maximum TBS size limit.
  • the MME may also provide whether the UE is to provide the acknowledgment for the small DL data. If the UE is to provide acknowledgement, the eNB may move the UE to the RRC CONNECTED mode. However, the eNB may still use DL EDT to transmit the small DL data in Msg4.
  • DL-EDT indication in paging an example of MT EDT or DL
  • EDT indication in paging message is shown below.
  • the Paging message may be used for the notification of one or more UEs.
  • Signalling radio bearer N/A.
  • RLC-SAP TM.
  • Logical channel PCCH.
  • Direction E-UTRAN to UE.
  • IMSI :: SEQUENCE (SIZE (6..21)) OF IMSI- Digit
  • one of the pool of configured reserved dedicated preambles can be indicated in the paging.
  • the size of pool for the preamble can depend on the configuration of reserved dedicated preambles.
  • the size of pool can be fixed and can be taken as the first Nth preambles from the pool.
  • the value of N can be 2 or 4 or maxPageRec. An example is shown below.
  • PagingRecordList SEQUENCE (SIZE (L.maxPageRec)) OF PagingRecord
  • PagingRecordList SEQUENCE (SIZE (L.maxPageRec)) OF PagingRecord
  • PagingRecordList SEQUENCE (SIZE (L.maxPageRec)) OF PagingRecord
  • Dl-EDT-PreambleIndex-rl6 ENUMERATED ⁇ Null, Preamble-1, Preamble-2, Preamble- 3 ⁇
  • a separate paging record list can be created that is only applicable to UEs in CE.
  • the index order of the list PagingEDT- IndicationList and the original PagingRecordList should belong to the same UE, however, the size of the list can be different.
  • PagingEDT -IndicationList : : SEQUENCE (SIZE ( 1..maxPageRec)) OF PagingEDT -
  • PagingRecordList SEQUENCE (SIZE (L. maxPageRec)) OF PagingRecord
  • IMSI : : SEQUENCE (SIZE (6..21)) OF IMSI-Digit
  • the eNB may also provide the size of DL data so that the UE can decide whether or not to use DL EDT or whether to provide a DL EDT indication via Msgl or Msg3 that the EE is ready to receive data in Msg4 based on the CE level. This is because the TB that can be transmitted depends on CE level and the eNB would not be aware of the CE level until the eNB receives Msgl from the EE.
  • PagingEDT-Indication :: SEQUENCE ⁇
  • the eNB may indicate all PRACH resources (or preambles) corresponding to each CE level as the eNB may not be aware of the CE level the EE is in. The EE may then respond with the correct preamble based on its CE level. Alternatively, the eNB may indicate a preamble for CE level 0 The preamble for CE level x may be determined as preamble + x.
  • Paging message with payload in another option, payload or DL
  • EDT data may be included in the paging message only if TIE is a stationary TIE or the location of the TIE is known to the MME.
  • the MME may attempt to send the paging only to the eNB where the TIE was connected to last time. If the MME does not hear from the TIE, then the MME may follow the paging retransmission without DL data payload or with only DL data indication.
  • the LIE can send the NAS signaling using the configured PETSCE1 resource or EIL semi- persistent scheduling (SPS).
  • the resource can be configured by a dedicated RRC message to one LIE or to a group of EIEs for sharing to send an ACK upon paging.
  • the indication for activation of the configured EIL resource can be sent in the paging message.
  • NAS signaling may be sent as an ACK in the configured EIL resource as Msg3 and Msg4 is scheduled by the eNB to indicate successful reception of Msg3 and the EE can enter the Idle mode.
  • the EE may be configured with dedicated preconfigured uplink and/or downlink resources while in RRC CONNECTED mode.
  • the context or information of the dedicated preconfigured resource and/or cell-specific RNTI to scramble the data in the PDSCH/PEISCH may be provided to the MME transparently.
  • the MME may send the S 1 AP paging together with the DL data, such information of the dedicated preconfigured resource and/or cell-specific RNTI to scramble the data in the PDSCH/PEISCH so that the eNB can activate the resource for the EE in the Idle mode via RAN paging (with some activation indication).
  • a preconfigured DL resource may be used for MT data and a preconfigured UL resource may be used for acknowledgement. After successful acknowledgement, the preconfigured resource can be implicitly disabled.
  • the MME can also indicate a NAS specific RNTI or a tracking area specific RNTI to scramble the PDSCH/PUSCH. In another option, this procedure may apply only to a stationary UE or only to the eNB where the UE was connected the last time or to a group of eNBs or only a few selected or recommended eNBs.
  • X preconfigured uplink and/or downlink resources may be defined.
  • the X resources may be identified by resource mapping indices, and which resource to use may be indicated in paging by the corresponding cells. Unless activated via paging, such resources are not wasted and may be used for other purposes.
  • X can be flexible to allocate resources or preconfigure resources for X cells or eNBs or within a tracking area.
  • the UE may use the preamble (PRACH resource) indicated in the paging message to receive a UL grant to send Msg3.
  • the UE may send the NAS signaling in Msg3 and return to the Idle mode.
  • the eNB may forward the NAS signaling to the MME.
  • the UE may return to the Idle mode after receiving a contention resolution ID (or after contention resolution is successful).
  • the MME may send the paging message with
  • the eNB may send the paging message with DL data (MT data) indication to the rest of the eNBs in the tracking area.
  • MT data DL data
  • the UE may refrain from taking further action and stay in the Idle mode. In this case, the UE may be unable to receive the packet correctly, instead sending a NAS service request in Msg3 and receiving the DL data in Msg4.
  • the MME may assign to the UE a security code that is stored as a new RNTI, e g., EDT-RNTI.
  • the MME may provide the EDT-RNTI code to the eNB during Sl AP paging to scramble the DL data transmitted via or scheduled via paging, i.e. a PDSCH scrambled with the EDT-RNTI.
  • the eNB can also provide a cell-specific EDT-RNTI for the UE to the MME while releasing the UE to the idle mode.
  • RNTI length is x bits in length
  • x bits e.g., MSB or LSB
  • the new security code is for an additional layer of protection at the AS on the top of the NAS security.
  • MME-specific EDT-RNTI (or security code) has a validity time. After the expiry of the validity timer, the UE either has to request a new code with the MME and MT EDT may be unable to be used unless a new code (EDT-RNTI) is assigned.
  • EDT-RNTI a new code
  • a set of security codes (N security codes or EDT- RNTI) are negotiated and each one is used differently for each MT data (DL NAS PDU) in a sequence or random or predefined order. When there are no more codes left or all codes are used up, a new set of security codes may be negotiated between the UE and the MME.
  • the UE NAS may initiate a new NAS service request message with a new establishment cause or indication that the NAS security failed for data in the paging message to receive the DL data and a new security code (or EDT-RNTI scrambling code) correctly in Msg4.
  • the UE NAS may always initiate a new attach procedure to establish a new NAS security between the UE and the core network.
  • a new EDT-RNTI (security code) is also included.
  • the security code and MT data may be both protected by NAS security.
  • the UE may also receive a new security code to receive the new NAS PDU in future and the old code may no longer be valid.
  • the MT data may be sent via paging or scheduled via paging by the eNB where the UE was last in RRC CONNECTED. Otherwise, the MT data may be sent via Msg4. The MME may send the MT data to the eNB that was the last serving eNB for the UE.
  • MT data in the PDSCH is ciphered.
  • the UE may also activate AS security and receive the PDSCH.
  • the new dedicated PRACH preamble or resource information may also be included and ciphered so that the UE can send feedback (ACK/NACK).
  • ACK/NACK feedback
  • the eNB may schedule the retransmission via another paging message or indicate to the MME to fallback to the legacy paging mechanism.
  • the UE may return to the Idle mode with a suspend indication after sending the dedicated preamble.
  • a NACK preamble
  • the UE may monitor the common search space (CSS) for the given RNTI and may expect a PDCCH scheduling the retransmission of the PDSCH.
  • the UE may initiate the random access procedure to resume the RRC connection.
  • Sl AP paging with MT data may be sent to all eNBs one by one and the above process may be repeated until the UE sends feedback to the eNB.
  • the UE may be in Idle mode and have no stored UE context.
  • the MME may negotiate with each eNB to add a dedicated PRACH preamble and resource for feedback in the NAS PDET in the tracking area. This can be done one at a time or all eNBs at the same time. If it is done one at a time (i.e., for delay tolerant EIEs or low mobile UEs), the MME may first obtain the PRACH resource for feedback and send the paging with encrypted DL data to the last serving eNB of the TIE. If there is no feedback, then the MME may repeat this to another eNB.
  • PRACH preamble configuration in another option, the PRACH preamble can be configured using a common RACH configuration as shown in the example below.
  • the TIE may use the PRACH preambles only if the DL- EDT indication is received in the paging message. In another option, the TIE may always use the preambles in response to a paging message.
  • the other PRACH resource and parameters may be same to that configured for Rel-l5 EIL EDT.
  • RACH-ConfigCommon The IE RACH-ConfigCommon is used to specify the generic random access parameters.
  • n4 n8, nl2, nl6, n20, n24, n28, n32, n36, n40, n44, n48, n52, n56, n60 ⁇ ,
  • connEstFailCount-rl2 ENUMERATED ⁇ nl, n2, n3, n4 ⁇ , connEstFailOffsetValidity-rl2 ENUMERATED ⁇ s30, s60, sl20, s240 :
  • RACH-CE-LevellnfoList-rl 3 SEQUENCE (SIZE (L.maxCE-Level-rl3)) OF RACH-CE- LevelInfo-rl3
  • preambleMappingInfo-rl3 SEQUENCE ⁇
  • ra-ResponseWindowSize-rl3 ENUMERATED ⁇ si20, sf50, sf80, sfl20 : sfl80, sf240, sf320, sf400 ⁇ , mac-ContentionResolutionTimer-rl3 ENUMERATED (sf80, sflOO, sfl20, sf!60, sf200, sf240, sf480, sf960 ⁇ ,
  • the UE may use the same PRACH resource and parameters as a legacy PRACH resource configured for the enhanced coverage. Only the preamble may be dedicated for DL EDT.
  • edt-TBS-rl5 ENUMERATED ⁇ b328, b408, b504, b600, b712, b808, b936, bl000or456 ⁇ , mac-ContentionResolutionTimer-rl5 ENUMERATED ⁇ sf240, sf480, sf960, sfl920, sf3840, sf5760, sf7680, sfl0240 ⁇
  • the UE may also report the DL-EDT capability in UE-EUTRA-Capability or in UE-RadioPaginglnfo IEs as follows.
  • the MME can send this container to the eNB when sending the Sl AP paging message. This helps the eNB determine the UE’s DL-EDT capability.
  • the eNB optionally can send the DL-EDT indication in the RAN paging message and also provide a sufficiently larger grant in the RAR for UEs to send a NAS service request in Msg3 for CP solutions.
  • the eNB can assume a DL-EDT capable UE may always activate AS security before Msg3.
  • the UE may send the CP DL-EDT or UP DL- EDT capability in the RRCConnectionSetupComplete message so that the MME can store the capability in its context for later use.
  • the UE’s capability on the support of scheduling of multiple transport blocks by a single PDCCH can also be indicated in UE-RadioPaginglnfo to let the eNB decide whether or not to use DL-EDT during paging. This may indicate whether the DL EDT small data size is large enough that the data cannot be transmitted in a single transport block.
  • the UE-RadioPaginglnfo IE contains UE capability information needed for paging.
  • ce-ModeA-rl3 ENUMERATED ⁇ true ⁇ OPTIONAL
  • ce-ModeB-r!3 ENUMERATED ⁇ true ⁇ OPTIONAL
  • the IE UE-EUTRA-Capability is used to convey the E-UTRA UE Radio Access Capability Parameters, see TS 36.306, and the Feature Group Indicators for mandatory features (defined in Annexes B.1 and C.1) to the network.
  • the IE UE-EUTRA-Capability is transferred in E-UTRA or in another RAT.
  • Capability indication in RRCConnectionSetupComplete message If the MME is to store the DL-EDT capability of the UE, this indication can be provided in Msg4 (RRCConnectioSetupComplete message) when the UE enters RRC CONNECTED mode. In this case, whenever there is small DL data, the MME can decide whether or not DL-EDT should be used. Similarly, to help the MME to decide whether or not to use DL EDT based on the size of the DL data, the support of scheduling of multiple transport blocks using a single PDCCH can be indicated. An example is shown below.
  • the RRCConnectionSetupComplete message may be used to confirm the successful completion of an RRC connection establishment.
  • Signalling radio bearer SRB1.
  • RLC-SAP AM.
  • Logical channel DCCH.
  • mobilityState-r12 ENUMERATED ⁇ normal, medium, high, spare) OPTIONAL
  • the UE can also use a new RRC message with CCCH message class extension (RRCResumeEarlyDownlinkDataRequest message or RRCResumeEarlyDataRequest message) to let the network know that the UE has already activated AS security before Msg3.
  • a new RRC message with CCCH message class extension RRCResumeEarlyDownlinkDataRequest message or RRCResumeEarlyDataRequest message
  • the UL-CCCH-Message class is the set of RRC messages that may be sent from the UE to the E-UTRAN on the uplink CCCH logical channel. — ASN1START
  • the RRCResumeEarlyDownlinkDataRequest message may be used to request the resumption of a suspended RRC connection or to perform Mobile Terminated UP-EDT.
  • Signalling radio bearer SRB0.
  • RLC-SAP TM.
  • Logical channel CCCH.
  • resumeID-rl6 ResumeIdentity-r13, shortResumeMAC-I-rl6 BIT STRING (SIZE (16) ) , resumeCause-r16 ENUMERATED ⁇ mt- Access, spare) ,
  • the eNB can also broadcast whether or not DL-EDT is supported. If the eNB supports DL-EDT, then the eNB can let the TIE know that for each RRC connection request message in response to a paging message, the eNB will provide a larger EIL grant in the RAR for the TIE to send the NAS service request in Msg3 for the CP solution. For the TIP solution, if the eNB supports DL-EDT and provides an indication in system information, the LIE may activate AS security before Msg3 based on the Next Hop Chaining Counter (NCC) received in the previous suspend procedure.
  • NCC Next Hop Chaining Counter
  • the duration can be defined as a new timer.
  • the duration can be equal to N discontinuous reception (DRX) cycles, contention resolution timer, RA window size, or paging retransmission time.
  • the length duration can also be broadcast in the system information.
  • the IE SystemInformationBlockType2 contains radio resource configuration information that is common for all UEs.
  • OPTIONAL Need OP radioResourceConfigCommon RadioResourceConfigCommonSIB, ue-TimersAndConstants UE-TimersAndCons tants ,
  • timeAlignmentTimerCommon TimeAlignmentTimer
  • FIG. 4 illustrates use of direct indication information for MT EDT in accordance with some
  • FIG. 5 illustrates details of MT EDT transmission in accordance with some embodiments.
  • the PRACH resource for the MT EDT can be used for feedback for the MT EDT data as shown in FIG. 5.
  • the same mechanism can be used to request MT EDT data to the eNB after receiving an indication of MT EDT in the paging message.
  • a contention free PRACH resource to use may be derived from the UE’s ID.
  • an x bit (e.g., 10 bit) HASHED ID may be calculated from the UE ID or using some function of the UE ID or IMSI or S- TMSI or UE ID H as in eDRX.
  • UE ID H - 10 most significant bits of the Hashed ID, if the P- RNTI is monitored on the PDCCH or MPDCCH or - 12 most significant bits of the Hashed ID, if the P-RNTI is monitored on the NPDCCH.
  • the MSB (or LSB) y bit (i.e., 6 bits) may be used as a Preamble index and LSB (or MSB) z bits (i.e., 4 bits or 3 bits) may be used as a PRACH mask index which tells the UE on which subframe the UE is allowed to transmit the preamble.
  • Preambleindex-ybit a further r bits of a contention free preamble can be derived as numberOfRA-Preambles + Preambleindex-ybit mod (64 - numberOfRA- Preambles) or s bits of contention based preambles can be derived as
  • Preambleindex-ybit mod numberOfRA-Preambles When the preambles are partitioned for the CE level, the preambles can be derived as Preambleindex-ybit mod (1 + larstPreamble-rl3 - firstPreamble-rl3).
  • UE ID H that is used for eDRX can also be used as an x bit HASHED ID.
  • An example of a paging record list indicating integer values of PRACH MASK index for MT EDT the value 1 may indicate the first PRACH resource index and so on. Or the PRACH MASK index can be included.
  • PagingRecordList SEQUENCE (SIZE (L.maxPageRec)) OF PagingRecord PagingRecord SEQUENCE ⁇
  • Dl-EDT -PRACH-Masklndex-r 16 ENUMERATED ⁇ No-MT-EDT, indexO, Index 1, Index2, Index3, Index4, ...,Indexl4 ⁇
  • a contention free preamble index may be determined from the HASHED ID or some function of UE ID or S-TMSI (i.e., UE ID H). Contention free preambles may be determined from numberOfRA- Preambles to 63. In another option, the UE may randomly choose one of the contention free preambles.
  • the preamble index numberOfRA-Preambles + UE ID mod (64 - numberOfRA-Preambles).
  • the preamble index refers to the NPRACH subcarrier index so the PRACH mask index is not required in paging.
  • Preamble index nprach-SubcarrierOffset + nprach-NumCBRA- StartSubcarriers + (UE ID modulo (nprach-NumSubcarriers - nprach- NumCBR A- Start Sub carri er s)) .
  • the UE may determine the CE level and use the PRACH resource for that CE level. The only difference is the UE may follow the PRACH MASK index (and/or preamble index) indicated in the paging message, the preamble index may be determined from the UE’s ID. In addition, the UE may always use a number of preamble transmissions equal to
  • numRepetitionPerPreambleAttempt-rl3 +x (or -x).
  • the value of x can be predefined or indicated in paging, broadcast or configured by dedicated RRC signaling and stored in the MME as paging assistance information.
  • the value of x can be 1. This means that the UE in response to MT EDT paging may use numRepetitionPerPreambleAttempt-rl3 +x (-x) repetitions of preamble whereas all other UEs may use the configured number of repetitions
  • the eNB may have to at least receive the first repetition and the additional repetitions x.
  • the x additional repetition(s) may be made in the PRACH resource index +1 (or some other implicitly or explicitly indicated/derived PRACH resource index) or after finishing the numRepetitionPerPreambleAttempt.
  • the UE when using the preamble index and PRACH resource index implied from the paging message, may use at least one parameter different from the configured PRACH resource parameters for a CE level, for example, the number of preamble repetitions, prach-FreqOffset-rl3, prach-StartingSubframe-rl3, rootSequencelndex etc, so that the eNB can distinguish the MT EDT intended UE in case of collision.
  • a CE level for example, the number of preamble repetitions, prach-FreqOffset-rl3, prach-StartingSubframe-rl3, rootSequencelndex etc.
  • the eNB determines that a different PRACH mask index and preamble index are unable to be allocated to two UEs having MT EDT data, then the eNB can send the MT EDT data one at a time.
  • an MT EDT-enabled UE may monitor a PDCCH with both a PRNTI and new RNTI (EDT-RNTI) in the legacy PO to receive paging.
  • the PDCCH with the EDT-RNTI may schedule a paging message that carries the small DL data.
  • the UE may start monitoring the PDCCH in the CSS with the new RNTI (EDT-RNTI) that schedules the PDSCH carrying the MT EDT data.
  • a set of RNTI (e g. (EDT-RNTI- 1 to EDT-RNTI- N ⁇ ) can be defined and hardcoded (e.g., reserved as FFF8, FFF7 etc.). This can be cell-specific and broadcast in the system information. In some embodiments, the set may be limited to containing only one RNTI.
  • N MT EDT data can be scheduled at a time.
  • the offset can be predefined, hardcoded or broadcast.
  • the offset multiplier (n bits) can be included in the paging record list of the EEs. Or the offset multiplier can be the index to the paging record list for the UE.
  • RNTI for UE1 EDT-RNTI
  • RNTI for UE2 EDT- RNTI - offset x Offset multiplier.
  • the new PRNTI may be derived from the UE’s ID (e.g., IMSI, S TMSI) or other paging parameters such as a paging narrow band (PNB) or non-anchor carrier. Similar to RA-RNTI, EDT-RNTI can be calculated from the paging occasion. One example is shown below.
  • EDT-RNTI l+t_id + l0*f_id + 60*(SFN_id mod (Wmax/lO))
  • t_id is the index of the PO (0 ⁇ t_id ⁇ 10)
  • f id is the index of the paging narrowband (0 ⁇ f_id ⁇ 16)
  • Wmax is the retransmission window for MT EDT data.
  • direct indication information on the MPDCCH or NPDCCH using the P-RNTI but without associated paging message may be used to indicate MT EDT data available.
  • the x reserved bit can also serve as an offset to the already-known P- RNTI value or EIE-specific EDT-RNTI value.
  • the RNTI used to receive MT EDT P-RNTI - multiplier X RNTI-Offset, where the multiplier can be 1 or pre-defmed.
  • the EDT-RNTI can be a UE-specific RNTI (or previous C-RNTI).
  • the offset may be from the UE-specific RNTI.
  • the n bit RNTI-Offset may be derived from S TMSI so the UE can know whether or not the RNTI is intended for the UE.
  • the UE may check multiple RNTIs.
  • the UE may monitor the PDCCH with new EDT-PRNTI to receive the MT EDT data.
  • the EDT-RNTI could be UE-specific derived from the UE ID or negotiated with the MME, and the MME may deliver the EDT- RNTI to the eNB as paging assistance information. If such a UE-specific EDT- RNTI is used up in the cell, the eNB may inform the MME or start the legacy paging or wait until such an EDT-RNTI is available.
  • the reserved bit in DCI can also be used to derive/indicate a PRACH resource index and preamble index.
  • the UE may use a UE-specific RNTI to receive the MT EDT data.
  • MT EDT data if MT EDT data is delivered via paging or scheduled after paging message or in Msg2, a genuine UE may miss paging while a fake UE could receive the data and send an acknowledgment. To detect this issue, the eNB may also indicate the indication of delivery of MT EDT in the next paging occasion. If the TIE sees an MT EDT delivery indication but not the MT EDT indication, the TIE should let the network know about the problem (e.g., NAS recovery). In one option, the eNB may send the MT EDT delivery indication in the paging message in the PO when there is a suspicious response from the TIE.
  • the eNB may send the MT EDT delivery indication in the paging message in the PO when there is a suspicious response from the TIE.
  • the eNB may be suspicious if the TIE uses a dedicated resource (e.g., PRACH resource) for the response or feedback with different parameters than indicated for MT EDT, for example, transmit power, number of repetitions, preamble format, preamble index, PRACH resource index etc.
  • a dedicated resource e.g., PRACH resource
  • the exact number of repetitions or ETL transmit power in the PRACH resource or PETCCH resource can be configured by dedicated RRC signaling and can be stored in the MME as paging assistance information.
  • Direct indication information on the MPDCCH or NPDCCH using the P-RNTI but without an associated paging message can be used to indicate an MT EDT delivery indication.
  • the TIE can use the PRACH resource dedicated for the MT EDT instead of the PRACH MASK and preamble indicated in paging.
  • the UE may use the indicated PRACH MASK index (with +k or -k) or Preamble index (with +k or -k) to distinguish between a HARQ ACK and a request for MO EDT in response to the MT EDT data.
  • the difference from the MO EDT procedure is that the EE can merely receive the PDCCCH-based EE HARQ ACK and return to the Idle mode after sending Msg3.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un système et des procédés de fourniture d'une prise en charge d'un EDT MT. Des informations système ou un message de radiomessagerie RRC envoyé à l'UE à partir de l'eNB indiquent des données EDT DL à transmettre à l'UE. Un préambule d'accès aléatoire transmis sur un PRACH est un préambule dédié pour une transmission de données EDT DL dépendant du niveau CE ou sélectionné dans un groupe de préambules EDT. La RAR transmise en réponse comprend une autorisation UL ayant des ressources UL permettant la transmission d'une demande de service. La demande d'EDT RRC envoyée en réponse indique que l'UE a activé la sécurité AS. Le message RRC transmis par l'eNB après l'indication de l'activation de sécurité AS dépend de si l'UE est capable de recevoir les données EDT DL, sur la base du niveau CE, et de si l'équipement utilisateur est capable d'éviter un accusé de réception des données EDT DL s'il est envoyé.
EP19865907.0A 2018-09-27 2019-09-26 Système et procédés permettant un edt dl Withdrawn EP3858064A4 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201862737486P 2018-09-27 2018-09-27
US201862753838P 2018-10-31 2018-10-31
US201962800341P 2019-02-01 2019-02-01
PCT/US2019/053121 WO2020069103A1 (fr) 2018-09-27 2019-09-26 Système et procédés permettant un edt dl

Publications (2)

Publication Number Publication Date
EP3858064A1 true EP3858064A1 (fr) 2021-08-04
EP3858064A4 EP3858064A4 (fr) 2022-06-22

Family

ID=69953326

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19865907.0A Withdrawn EP3858064A4 (fr) 2018-09-27 2019-09-26 Système et procédés permettant un edt dl

Country Status (3)

Country Link
EP (1) EP3858064A4 (fr)
CN (1) CN112400356A (fr)
WO (1) WO2020069103A1 (fr)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114270968A (zh) * 2019-05-01 2022-04-01 苹果公司 用于控制平面和用户平面解决方案中的mt edt的方法、设备和系统
CN112566273B (zh) * 2019-09-26 2022-12-23 维沃移动通信有限公司 一种数据接收、发送方法、终端及网络侧设备
WO2021203310A1 (fr) * 2020-04-08 2021-10-14 Oppo广东移动通信有限公司 Procédé et appareil de transmission de données et équipement terminal
CN113784436A (zh) * 2020-06-09 2021-12-10 大唐移动通信设备有限公司 指示方法及设备
CN113905457B (zh) * 2020-07-06 2023-08-08 维沃移动通信有限公司 消息发送方法、接收方法、装置及通信设备
CN116114365A (zh) * 2020-08-06 2023-05-12 上海诺基亚贝尔股份有限公司 用于随机接入或小数据传输的增强寻呼过程
CN116711441A (zh) * 2021-01-13 2023-09-05 上海诺基亚贝尔股份有限公司 用于分配用户设备的随机接入过程的方法、装置和计算机可读介质
WO2022200681A1 (fr) * 2021-03-22 2022-09-29 Nokia Technologies Oy Détermination de ressources d'accès aléatoire pour radiomessagerie de groupe
EP4271109A4 (fr) * 2021-04-02 2024-01-17 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Procédé de transmission de canal, dispositif électronique et support de stockage
US20240179755A1 (en) * 2021-05-06 2024-05-30 Qualcomm Incorporated Random access partitions for different use cases
WO2023015535A1 (fr) * 2021-08-12 2023-02-16 北京小米移动软件有限公司 Procédé et appareil pour effectuer une petite transmission de données, procédé et appareil pour déterminer un mode de transmission de message d'accès aléatoire, dispositif et support d'enregistrement
WO2023155998A1 (fr) * 2022-02-18 2023-08-24 Nokia Technologies Oy Attribution de ressources radio sensible à l'état de rrc et économe en énergie
US20240275540A1 (en) * 2023-02-13 2024-08-15 Apple Inc. Signaling-less Data Transfer

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6963544B1 (en) * 1999-12-10 2005-11-08 Lucent Technologies Inc. System for statistically multiplexing real-time and non-real-time voice and data traffic in a wireless system
RU2743580C2 (ru) * 2016-05-11 2021-02-20 Сони Корпорейшн Распределенное управление в системах радиосвязи

Also Published As

Publication number Publication date
CN112400356A (zh) 2021-02-23
EP3858064A4 (fr) 2022-06-22
WO2020069103A1 (fr) 2020-04-02

Similar Documents

Publication Publication Date Title
WO2020069103A1 (fr) Système et procédés permettant un edt dl
US10849181B2 (en) NR RRC connection setup optimisation
CN115397042B (zh) 使用预配置专用资源的空闲模式传输的状态转换
EP2747508B1 (fr) Procédé et dispositif pour une transmission de données
CN106792608B (zh) 小数据包传输方法、装置及终端
US20190208411A1 (en) Security framework for msg3 and msg4 in early data transmission
US9769700B2 (en) Overload control in a communication network
US10057920B2 (en) Proximity service channel allocation based on random access channel procedure
KR20180096726A (ko) 무선 통신 시스템에서 연결 재개 방법 및 이를 위한 장치
EP3549384A1 (fr) Dispositif de communications, procédés et équipement d'infrastructure
US20160073292A1 (en) Transmission of a random access response message
CN112970301B (zh) 针对寻呼消息中的下行链路早期数据传输的确认
CN102223715A (zh) 一种数据传输方法及装置
US11463938B2 (en) Managing control plane latency for integrated access and backhaul
EP3777424B1 (fr) Procédé et système de transmission d'identifiant temporaire
US11792641B2 (en) UE capability transfer and storage
WO2020139509A1 (fr) Protection d'intégrité pour transmission fréquente de petites données
CN111083798A (zh) 一种基于竞争的随机接入方法和装置
TW201714441A (zh) 處理系統資訊的裝置及方法
CN109587766B (zh) 按需系统信息请求响应、接收方法及装置、基站
CN109587767B (zh) 按需系统信息请求响应、接收方法及装置、基站
US11672014B2 (en) Transmission of a short contention resolution identifier
CN113632533B (zh) 一种数据处理方法、中继设备和网络设备
EP3429305B1 (fr) Procédé permettant à un équipement utilisateur (ue) d'accéder à un réseau
CN103546981B (zh) 竞争式随机接入的实现方法和装置

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20201116

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
A4 Supplementary search report drawn up and despatched

Effective date: 20220520

RIC1 Information provided on ipc code assigned before grant

Ipc: H04W 28/02 20090101ALI20220516BHEP

Ipc: H04W 76/27 20180101ALI20220516BHEP

Ipc: H04W 74/00 20090101ALI20220516BHEP

Ipc: H04W 74/08 20090101ALI20220516BHEP

Ipc: H04W 68/02 20090101ALI20220516BHEP

Ipc: H04W 72/14 20090101AFI20220516BHEP

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20240307