BE1022333B1 - Appareil et procede pour envoyer efficacement des messages de declenchement d'appareil. - Google Patents

Appareil et procede pour envoyer efficacement des messages de declenchement d'appareil. Download PDF

Info

Publication number
BE1022333B1
BE1022333B1 BE2013/0464A BE201300464A BE1022333B1 BE 1022333 B1 BE1022333 B1 BE 1022333B1 BE 2013/0464 A BE2013/0464 A BE 2013/0464A BE 201300464 A BE201300464 A BE 201300464A BE 1022333 B1 BE1022333 B1 BE 1022333B1
Authority
BE
Belgium
Prior art keywords
message
device trigger
request
information
trigger message
Prior art date
Application number
BE2013/0464A
Other languages
English (en)
Inventor
Puneet Jain
Varun Rao
Original Assignee
Intel Corporation
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 Corporation filed Critical Intel Corporation
Application granted granted Critical
Publication of BE1022333B1 publication Critical patent/BE1022333B1/fr

Links

Classifications

    • 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/1861—Physical mapping arrangements
    • 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/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0023—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the signalling
    • H04L1/0025—Transmission of mode-switching indication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/24—Radio transmission systems, i.e. using radiation field for communication between two or more posts
    • H04B7/26—Radio transmission systems, i.e. using radiation field for communication between two or more posts at least one of which is mobile
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • 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/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0023—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the signalling
    • H04L1/0026—Transmission of channel quality indication
    • 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
    • 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/1607—Details of the supervisory signal
    • H04L1/1628—List acknowledgements, i.e. the acknowledgement message consisting of a list of identifiers, e.g. of sequence numbers
    • 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
    • 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/1829—Arrangements specially adapted for the receiver end
    • H04L1/1854—Scheduling and prioritising arrangements
    • 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/1887—Scheduling and prioritising arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0048—Allocation of pilot signals, i.e. of signals known to the receiver
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053—Allocation of signaling, i.e. of overhead other than pilot signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053—Allocation of signaling, i.e. of overhead other than pilot signals
    • H04L5/0055—Physical resource allocation for ACK/NACK
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0058—Allocation criteria
    • H04L5/0064—Rate requirement of the data, e.g. scalable bandwidth, data priority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0058—Allocation criteria
    • H04L5/0073—Allocation arrangements that take into account other cell interferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/14—Two-way operation using the same type of signal, i.e. duplex
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1073—Registration or de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/10—Scheduling measurement reports ; Arrangements for measurement reports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0205—Traffic management, e.g. flow control or congestion control at the air interface
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0215—Traffic management, e.g. flow control or congestion control based on user or device properties, e.g. MTC-capable devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H04W28/0875—Load balancing or load distribution to or through Device to Device [D2D] links, e.g. direct-mode links
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/16—Performing reselection for specific purposes
    • H04W36/22—Performing reselection for specific purposes for handling the traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery
    • H04W48/12—Access restriction or access information delivery, e.g. discovery data delivery using downlink control channel
    • 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/0203—Power saving arrangements in the radio access network or backbone network of wireless communication networks
    • H04W52/0206—Power saving arrangements in the radio access network or backbone network of wireless communication networks in access points, e.g. base stations
    • 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
    • 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
    • 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/0245—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal according to signal strength
    • 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/04—TPC
    • H04W52/38—TPC being performed in particular situations
    • H04W52/383—TPC being performed in particular situations power control in peer-to-peer links
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H04W72/044—Wireless resource allocation based on the type of the allocated resource
    • H04W72/0446—Resources in time domain, e.g. slots or frames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H04W72/044—Wireless resource allocation based on the type of the allocated resource
    • H04W72/046—Wireless resource allocation based on the type of the allocated resource the resource being in the space domain, e.g. beams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/21—Control channels or signalling for resource management in the uplink direction of a wireless link, i.e. towards the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/23—Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/30—Resource management for broadcast services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/56—Allocation or scheduling criteria for wireless resources based on priority criteria
    • H04W72/566—Allocation or scheduling criteria for wireless resources based on priority criteria of the information or information source or recipient
    • H04W72/569—Allocation or scheduling criteria for wireless resources based on priority criteria of the information or information source or recipient of the traffic information
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/02—Inter-networking arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0215—Traffic management, e.g. flow control or congestion control based on user or device properties, e.g. MTC-capable devices
    • H04W28/0221—Traffic management, e.g. flow control or congestion control based on user or device properties, e.g. MTC-capable devices power availability or consumption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/08—Access point 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
    • 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
    • Y02E—REDUCTION OF GREENHOUSE GAS [GHG] EMISSIONS, RELATED TO ENERGY GENERATION, TRANSMISSION OR DISTRIBUTION
    • Y02E40/00—Technologies for an efficient electrical power generation, transmission or distribution
    • Y02E40/60—Superconducting electric elements or equipment; Power systems integrating superconducting elements or equipment

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Quality & Reliability (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Avec la prolifération de communications de type machine (MTC), une utilisation excessive de messages déclencheurs de dispositif dans un réseau d'évolution à long terme (LTE) peut avoir des effets négatifs sur un équipement utilisateur (EU). Ces effets peuvent comprendre un raccourcissement de la durée de vie de la batterie de l'EU et/ou une signalisation excessive provoquée par le passage fréquent d'un mode repos à un mode actif. Une fonction d'interfonctionnement de MTC (MTC-IWF) peut être configurée pour déterminer le statut d'un EU auquel un message déclencheur de dispositif est destiné. Si le message déclencheur de dispositif est de priorité basse et que l'EU est dans un état de repos, la MTC-IWF ou entité de gestion mobile (MME)/nœud de support GPRS de service (SGSN)/centre de commutation mobile (MSC) peut mettre le message déclencheur de dispositif en mémoire tampon.

Description

APPAREIL ET PROCÉDÉ POUR ENVOYER EFFICACEMENT DES MESSAGES DE DÉCLENCHEMENT D'APPAREIL
Domaine technique [0001] Les modes de réalisation concernent les communications sans fil. Certains modes de réalisation concernent les communications sans fil utilisées dans des réseaux de technologie d'évolution à long terme (LTE).
Contexte de l'invention [0002] Le déclenchement d'un appareil est le moyen permettant à un serveur de capacité de service (SCS) d'envoyer des informations à une pièce d'un équipement utilisateur (UE) par l'intermédiaire d'un réseau afin d'activer l'UE pour qu'il exécute des actions spécifiques à une application.
[0003] Un nombre important de messages de déclenchement d'appareil, couplé à de faibles requêtes de données, peut entraîner un flot de signaux dans le réseau et influencer la durée de vie de la batterie d'un appareil si l'UE bascule entre un état inactif et un état connecté. Cela s'avère particulièrement vrai pour des applications de données mobiles qui envoient fréquemment des messages de déclenchement d'appareil avec une petite quantité de données.
Brève description des dessins [0004] La figure 1 représente une vue générale d'un mode de réalisation de la présente invention.
[0005] La figure 2 représente un organigramme de l'opération d'un autre mode de réalisation de la présente invention.
[0006] La figure 3 représente un organigramme de l'opération d'un autre mode de réalisation de la présente invention.
[0007] La figure 4 représente un organigramme de l'opération d'un autre mode de réalisation de la présente invention.
[0008] La figure 5 représente un organigramme de l'opération d'un autre mode de réalisation de la présente invention.
[0009] La figure 6 représente un organigramme de l'opération d'un autre mode de réalisation de la présente invention.
[0010] La figure 7 représente un organigramme de l'opération d'un autre mode de réalisation de la présente invention.
Description des modes de réalisation [0011] La description et les dessins suivants représentent des modes de réalisations spécifiques de façon suffisante pour que les hommes du métier puissent les mettre en pratique. D'autres modes de réalisation peuvent incorporer des modifications structurelles, logiques, électriques, de procédé et autres. Les exemples illustrent simplement des variations possibles. Les composants et fonctions individuels sont proposés en option, sauf s'ils sont explicitement requis, et la séquence des opérations peut varier. Les parties et caractéristiques de certains modes de réalisation peuvent être inclues dans les parties et les caractéristiques d'autres modes de réalisation ou les remplacer. Les modes de réalisation mentionnés dans les revendications englobent tous les éléments équivalents disponibles de ces revendications.
[0012] Dans la description détaillée suivante, plusieurs détails spécifiques sont indiqués afin de permettre une compréhension approfondie de l'invention. Cependant, l'homme du métier comprendra que la présente invention peut être mise en œuvre sans ces détails spécifiques. Dans d'autres situations, des méthodes, procédures, composants et circuits bien connus peuvent de pas avoir été décrits en détails afin de ne pas rendre la présente invention confuse.
[0013] Bien que les modes de réalisation de l'invention ne soient pas limités à cet égard, les termes "pluralité" et "une pluralité" utilisés dans la présente description peuvent comprendre, par exemple, les termes "de multiples" ou "deux ou plus". Les termes "pluralité" ou "une pluralité" peuvent être utilisés tout au long du mémoire pour décrire deux ou plus de deux composants, dispositifs, éléments, unités, paramètres et similaire. Par exemple, "une pluralité de postes" peut comprendre deux postes ou plus.
[0014] Le projet de partenariat de troisième génération (3GPP) est un accord de coopération établi au mois de décembre 1998 afin de rassembler un certain nombre d'organismes de normes de télécommunication, connus sous le nom de "partenaires organisationnels" et qui comprennent actuellement l'Association of Radio Industries and Business (ARIB) (association des industries et des entreprises radio), la China Communications Standards Association (CCSA) (association des normes de communication de la Chine), l'European Télécommunications Standards Institute (ETSI) (institut européen des normes de télécommunication), l'Alliance for Télécommunications Industry Solutions (ATIS) (alliance pour des solutions dans l'industrie des télécommunication), la Télécommunications Technology Association (TTA) (association de la technologie des télécommunications et le Télécommunication Technology Committee (TTC) (comité de la technologie des télécommunications). La mise en place du 3GPP a été officiellement validée en décembre 1998 avec la signature de "l'accord de projet de partenariat de troisième génération".
[0015] 3GPP fournit des normes mondialement applicables en tant que spécifications techniques et des rapports techniques pour un système mobile de troisième génération sur la base de réseaux GSM élaborés et des technologies d'accès radio qu'ils supportent (par ex. système universel de télécommunication avec les mobiles (UTRA) pour des modes de duplexage par répartition de la fréquence (FDD) et des modes de duplexage par répartition dans le temps (TDD)). 3GPP fournit par ailleurs des normes pour la maintenance et le développement du réseau mondial pour les communications mobiles (GSM) en tant que spécifications techniques et des rapports techniques comprenant des technologies d'accès radio élaborées (par ex. le service général de radiocommunication par paquets (GPRS) et des GSM à débit amélioré (EDGE)). Les spécifications techniques concernant les normes actuelles associées à la téléphonie mobile sont généralement mises à la disposition du public par le biais de l'organisme 3GPP.
[0016] 3GPP étudie actuellement l'amélioration du système mobile 3 G et envisage des contributions (vues et propositions) orientées vers l'amélioration du réseau UTRA (UTRAN). Un ensemble d'exigences de haut niveau a été identifié par les ateliers 3GPP comprenant : un coût réduit par bit; une augmentation de la prestation de service (c'est-à-dire plus de services à moindre coût et de meilleure qualité); une flexibilité de l'utilisation des bandes de fréquences actuelles et nouvelles; une architecture simplifiée avec des interfaces ouvertes et une consommation d'énergie finale réduite/ raisonnable. Une étude de l'UTRA & et de l'UTRAN Long Term Evolution (UTRAN-LTE, également connu sous le terme 3GPP-LTE et E-UTRA) a débuté en décembre 2004 dans le but de développer un cadre pour l'évolution de la technologie d'accès radio 3GPP vers une technologie d'accès radio par paquets optimisée, à débit élevé et une faible latence. L'étude a examiné des modifications apportées à la couche physique de l'interface radio (liaison descendante et liaison ascendante) tels que des moyens destinés à supporter une transmission flexible avec une largeur de bande pouvant atteindre 20 MHz, l'introduction de nouveaux schémas de transmission et des technologies avancées à plusieurs antennes.
[0017] 3GPP-LTE est basé sur une interface radio incorporant des techniques de multiplexage par répartition orthogonale de la fréquence (OFDM). L'OFDM est un format de modulation numérique à plusieurs porteuses qui utilise un grand nombre de sous-porteuses orthogonales, espacées de manière étroite, pour supporter des canaux de données utilisateur respectifs. Chaque sous-porteuse est modulée selon un schéma de modulation conventionnel, comme une modulation d'amplitude en quadrature (QAM), à un taux de symbole (relativement) bas comparativement au taux de transmission de la fréquence radio (RF). En pratique, les signaux OFDM sont générés en utilisant un algorithme de transformation de Fourier rapide (FFT).
[0018] Les machines doivent souvent communiquer avec d'autres machines sans, ou avec une très faible intervention humaine. Auparavant, ces communications étaient effectuées par câble. Au fil du temps, les communications sans fil ont commencé à être utilisées. Grâce à la disponibilité de plus en plus croissante de la large bande mobile, la communication de machine à machine (MTC) par l'intermédiaire d'une large bande devient de plus en plus populaire. La MTC permet une communication entre des machines distantes en vue d'échanger des informations et d'exécuter des commandes sans avoir besoin d'une intervention humaine. Des exemples de l'utilisation d’une communication de machine à machine comprennent des capteurs distants, la télématique de santé, des appareils de mesure utilitaires télécommandés, des caméras de surveillance, des services de paiement de péage, l'automatisation de la chaîne de production et similaire. Par exemple, un dispositif peut surveiller l'état de fonctionnement d'un autre dispositif et rapporter les états à un serveur central. Sinon, un dispositif peut lire un appareil de mesure utilitaire et fournir les données à un service de facturation en vue de préparer des factures utilitaires mensuelles.
[0019] Quand un serveur souhaite activer ou déclencher un certain dispositif MTC, il peut transmettre un message de déclenchement de dispositif sur le réseau de service. Le message de déclenchement de dispositif peut être configuré de façon à démarrer une communication entre le dispositif MTC et le serveur.
[0020] L'envoi de messages de déclenchement d'un dispositif est le moyen permettant à un serveur de capacité de service (SCS) d'envoyer des informations à l'équipement utilisateur (UE) par l'intermédiaire du réseau 3GPP afin d'activer l'UE pour qu'il exécute des actions spécifiques à une application. Ces actions peuvent comprendre l'initiation d'une communication avec le SCS pour le modèle indirect ou un serveur d'applications (AS) dans le réseau pour le modèle hybride. Le déclenchement d'un dispositif peut être requis quand une adresse IP de l'UE n'est pas disponible ou joignable par le SCS/AS.
[0021] Un message de déclenchement de dispositif contient de manière typique des informations (par ex. IMSI< ID du port d'application et similaire) qui permettent au réseau d'acheminer le message à l'UE approprié et à l'UE d'acheminer le message à l'application appropriée. Les informations destinées à l'application sont appelées charge utile de déclenchement du dispositif. L'UE est agencé de façon à pouvoir faire la distinction entre un message qui contient des informations de déclenchement de dispositif et un autre type de message.
[0022] A la réception, côté UE, la charge utile de déclenchement de dispositif est examinée pour déterminer les informations qui déclenchent les actions associées à l'application. L'application dans l'UE peut exécuter certaines actions indiquées, comme celle consistant à démarrer immédiatement une connexion ou effectuer une communication ultérieure avec le serveur de capacité de service SCS ou le serveur d'application AS sur la base des informations comprises dans la charge utile de déclenchement.
[0023] Un registre de facturation des données (CDR) peut être récupéré pour le déclenchement du dispositif. C'est-à-dire que le prestataire peut conserver une trace du coût de la transmission des données à des fins de facturation ultérieure.
[0024] En faisant référence à la figure 1, un schéma de principe illustrant l'architecture d'une communication de machine à machine (MTC) sous 3GPP est représenté.
[0025] Un équipement utilisateur UE 102 est représenté comme exécutant une application MTC UE 104. L'UE est couplé à un réseau d'accès radio (RAN) 106. Par l'intermédiaire du RAN 106, l'UE est couplé à différents composants du noyau évolué de traitement de paquets, comme le commutateur du service mobile (MSC) 108, l'entité de gestion mobile (MME) 110, le nœud de support GPRS de service (SGSN) 111 et la passerelle de service (S-GW) 112. Ensemble, ces composants constituent le réseau mobile terrestre public visité (VPLMN). Les composants dans le réseau mobile terrestre public domestique (HPLMN) sont couplés aux composants susmentionnés par l'intermédiaire de plusieurs points de référence.
[0026] La MME 110 peut, conjointement avec le SGSN 111, être agencée de façon à exécuter les fonctionnalités suivantes consistant à: recevoir un message de déclenchement de dispositif en provenance de la MTC-IWF; encapsuler des informations de déclenchement de dispositif dans un message NAS envoyé à l'UE utilisé pour MTC; recevoir un accusé de réception de déclenchement de dispositif en provenance de l'UE de déclenchement; rapporter la réussite/ l'échec de la livraison de déclenchement de dispositif à la MTC-IWF; et fournir des informations de charge/ encombrement SGSN/MME à la MTC-IWF.
[0027] Le point de référence Tsp (120) est utilisé par un serveur de capacité de service pour communiquer avec une fonction d'interfonctionnement MTC (MTC-IWF) 130. Le point de référence T5a (122) est utilisé pour coupler MTC-IWF et SGSN 111. Le point de référence T5b (124) est utilisé pour coupler MTC-IWF et un MME de service. Le point de référence T5c (126) est utilisé pour coupler MTC-IWF et un MSC de service. Le point de référence T5d (128) est utilisé pour coupler MTC-IWF et le serveur d'abonnement domestique.
[0028] Une MTC-IWF 130 peut être une entité autonome ou une entité fonctionnelle située dans une autre entité de réseau. Une MTC-IWF peut résider dans un réseau mobile terrestre public domestique (HPLMN). La MTC-IWF peut présenter de nombreuses fonctions différentes comprenant, sans limitation: la terminaison des points de référence Tsp, S6m et Rf7Ga; la terminaison d'un ou de plusieurs points de référence parmi les points T4, T5a, T5b et T5c; la possibilité d'autoriser le SCS avant l'établissement d'une communication par l'intermédiaire du réseau 3GPP; la possibilité d'autoriser des requêtes de plans de contrôles à partir d'un SCS.
[0029] La MTC-IWF 130 peut également supporter les fonctionnalités de déclenchement de dispositif suivantes consistant à : recevoir une requête de déclenchement de dispositif en provenance du SCS; rapporter au SCS l'acceptation ou le refus de la requête de déclenchement de dispositif; rapporter au SCS la réussite ou l'échec d'une livraison de déclenchement de dispositif; possibilité d'appliquer un contrôle de charge/ encombrement induit par MTC-IWF et/ou SGSN/MME dans la réponse aux requêtes de déclenchement, et utiliser un identifiant normalisé (par ex. ID du port d'application) afin de permettre à l'UE de faire la distinction entre un message MT transportant des informations de déclenchement de dispositif et un autre type de message.
[0030] La MTC-IWF 130 peut également supporter un dispositif de résolution de serveur d'abonnement domestique (HS S) destiné à être utilisé quand de multiples HSS séparés à adresser ont été déployés par l'opérateur de réseau; interroger l'HSS approprié quand cela est requis pour un déclenchement de dispositif pour a) cartographier E.164 MSISDN ou un identifiant externe à l'IMSI; b) extraire des informations de nœud de service pour l'UE (par ex. identifiant SGSN/MME/MSC de service); et c) déterminer si un SCS est autorisé à envoyer un déclencheur de dispositif à un UE particulier.
[0031] La MTC-IWF 130 peut également supporter la sélection de la plupart des dispositifs de livraison de déclenchement de dispositif efficaces et effectifs et protéger ce détail du SCS sur la base des informations de nœud de service UE actuelles en provenance de HSS/HLR (par ex. identifiant MME/SGSN/MSC de service); les dispositifs de livraison de déclenchement de dispositif supportés par l'UE, les services de livraison de déclenchement de dispositif possibles supportés par l'HPLMN et, lors d'une itinérance (roaming), VPLMN; le dispositif défini par l'opérateur déclenche des politiques de livraison, le cas échéant; et/ ou en option, toute information reçue par le SCS; traduction de protocole, si nécessaire, et réacheminement vers l'entité de réseau concernée (à savoir le SGSN/MME/MSC ou le SMS-SC de service au sein du domaine HPLMN) d'une requête de déclenchement de dispositif afin de correspondre au dispositif de livraison de déclenchement sélectionné; génération d'un CDR de déclenchement de dispositif avec un identifiant externe et identifiant SCS et réacheminement vers le CDF/CGF en l'occurrence de Rf7Ga; et possibilité d'une communication sécurisée entre le réseau 3GPP et le SCS.
[0032] Bien qu'un seul MTC-IWF soit représenté sur la figure 1, on comprendra que plusieurs MTC-IWF peuvent fonctionner dans un seul HPLMN.
[0033] Le Serveur pour Abonnés Résidentiels (HSS) 150 peut être configuré de manière à prendre en charge les fonctionnalités suivantes : clôture du point de référence S6m où les MTC-IWF se connectent au Registre de Localisation (HLR)/HSS ; conservation et fourniture au MTC-IWF (et de manière optionnelle au MTC AAA) la correspondance ou la recherche du Numéro de Données d’Abonné International à la Station Mobile (MSISDN) ou d’identifiants externes à l’Identificateur d’Abonné Mobile International (IMSI) et les informations d’abonnement utilisées par MTC-IWF pour le déclenchement d’appareil ; correspondance des MSISDN ou identifiants externes à IMSI ; de manière optionnelle, l’association des Identifiants Externes aux MSISDN est également fournie pour des infrastructures de SMS héritées qui ne prennent pas en charge les SMS sans MSISDN ; les « Informations de Routage » conservées par le HSS, comprenant des informations du nœud en service si disponible pour l’UE (p. ex. l’identifiant SGSN/MME/MSC en service) ; et la détermination de l’état d’autorisation d’un SCS à transmettre un signal d’appareil à un UE donné ; clôture du point de référence S6n ; fourniture au MTC-AAA la correspondance entre IMSI et identifiant(s) exteme(s).
[0034] Le Serveur de Capacité de Services 132 est agencé de manière à coupler un serveur d’application 134 au MTC-IWF 130dans un modèle indirect. Dans un modèle direct, le serveur d’application 136 est directement couplé au réseau de l’opérateur de manière à assurer des communications de plan utilisateur directes avec l’UE sans recours à un SCS externe.
[0035] Comme expliqué ci-dessus, un grand volume de déclenchement d’appareils, associé à de petites demandes de données, peut occasionner une poussée de signalisation sur le réseau. Ceci peut avoir un impact négatif sur la durée de vie de la batterie d’un article d’équipement utilisateur (UE) parce que l’UE peut devoir basculer plus souvent que nécessaire entre un état de veille et un état connecté. Plusieurs solutions sont possibles.
[0036] En référence à la FIG. 2, un organigramme présentant un mode de réalisation est représenté. Dans ce mode de réalisation, la Fonction d’interfonctionnalité de MTC (MTC-IWF) obtient l’état de l’UE depuis un Service d’Abonné Résidentiel (HSS), en utilisant un modèle indirect.
[0037] Un Serveur de Capacité de Services (SCS) détermine la nécessité de déclencher l’appareil (202). Si le SCS ne possède pas les coordonnées d’un MTC-IWF, il peut en premier lieu déterminer la ou les adresse(s) IP et le(s) port(s) d’un MTC-IWF en effectuant une requête DNS en utilisant l’identifiant Externe ou au moyen d’un identifiant de MTC-IWF (204) configuré localement.
[0038] Le SCS transmet ensuite un message de Demande de Déclenchement d’Appareil au MTC-IWF (206). Le message peut contenir des informations telles que l’identifiant Externe ou le MSISDN, l’identifiant du SCS, le numéro de référence du déclencheur, la période de validité, la priorité, l’ID du port d’application, la charge du déclenchement, et ainsi de suite. Le SCS inclut une Charge de Déclenchement qui peut contenir les informations destinées à l’application du MTC, ainsi que les informations nécessaires à leur acheminement jusqu’à celle-ci. L’ID de Port d’Application est définie pour adresser une fonction de déclenchement interne à l’UE.
[0039] Il convient de noter que des termes tels que « Requête de Déclenchement d’Appareil » ne sont employés qu’à des fins d’illustration. Le nom réel du message utilisé peut être différent.
[0040] Le MTC-IWF vérifie que le SCS est autorisé à envoyer des demandes de déclenchement et qu’il n’a pas dépassé son quota ou taux de soumission de déclenchements par Tsp (208). Si cette vérification échoue, le MTC-IWF transmet un message de Confirmation de Déclenchement d’Appareil contenant une valeur de cause indiquant la raison de l’échec et le flux s’arrête à cette étape.
[0041] Le MTC-IWF transmet au IMSI un message de Requête d’information Abonné (SIR) au HSS pour déterminer si le SCS est autorisé à déclencher l’UE (Identifiant Externe ou Identifiant MSISDN et SCS, Requête d’informations d’État d’UE) pour résoudre l’identifiant Externe ou le MSISDN, recevoir les identités du ou des nœuds desservant l’UE (210). L’indicateur de requête d’informations d’état d’UE est fixé de manière à demander les informations sur l’état de l’UE (comme Inactif, Connecté et Enregistré) au HSS (212). Ces informations indiquent également au HSS de s’inscrire aux notifications d’accessibilité au cas où l’UE ne serait pas accessible.
[0042] Le MTC-IWF peut être configuré de manière à effectuer des autorisations de mise en cache et des informations de routage pour l’UE. Cependant, ceci peut augmenter la probabilité d’échecs de tentatives de livraison de déclencheur si les informations de nœuds en service mises en caches sont périmées.
[0043] Le HSS envoie le message de Réponse d’informations d’Abonné (IMSI et identités des nœuds en service, Informations d’État d’UE) (214). La politique de l’HSS peut avoir une influence sur les identités des nœuds en service retournées. Si la valeur de cause indique que le SCS n’est pas autorisé à envoyer un message de déclenchement à cet UE ou si des informations d’abonnement valides n’ont pas été renvoyées par le HSS, le MTC-IWF renvoie un message de Confirmation de Déclenchement d’Appareil contenant une valeur de cause indiquant la raison de la condition d’échec, et le flux s’interrompt. Sinon, le flux se poursuit.
[0044] Si l’UE n’est pas accessible, le HSS ne peut renvoyer les identités des nœuds en service ou les informations d’état, ce qui fournit une indication implicite que l’UE n’est pas accessible, et dans ce cas, le MTC-IWF conserve le déclencheur su la période de validité n’indique pas qu’il s’agit d’une tentative unique de livraison.
[0045] Le MTC-IWF obtient ensuite l’état de l’UE dans le message de Réponse d’informations Abonné, et décide s’il doit placer le message de déclenchement dans le tampon ou le délivrer (216). Ce processus peut se dérouler de plusieurs façons. Un exemple est détaillé plus avant dans la FIG. 3. Quand le MTC-IWF décide de transmettre le message de déclenchement d’appareil, il sélectionne une procédure de livraison de déclencheur sur la base des informations reçues du HS S et de la politique locale. La procédure de livraison est sélectionnée et le MTC-IWF tente une procédure de livraison de déclencheur (218).
[0046] Le MTC-IWF transmet au SCS le message de Rapport de Déclenchement d’Appareil (Identifiant Externe ou MSISDN et numéro de référence de déclencheur) avec une valeur de cause indiquant si la livraison de déclencheur a réussi ou échoué et la raison de l’échec (220). Le MTC-IWF génère les informations CDR nécessaires, y compris l’identifiant Externe ou le MSISDN et l’identifiant du SCS (222).
[0047] En réponse au déclencheur d’appareil reçu, l’UE effectue des actions spécifiques qui prennent en compte le contenu de la charge de déclenchement (224). Cette réponse comprend en général l’initiation d’une communication immédiate ou retardée avec le SCS ou un AS. Cette action dépend de la nature de l’UE chargée d’agir.
[0048] L’ organigramme en FIG. 3 représente le comportement du MTC-IWF sur réception des informations d’état d’UE. Après réception du message de Réponse d’informations Abonné (302), le MTC-IWF valide l’abonné et vérifie l’état de l’UE (304). La priorité du déclencheur d’appareil est alors vérifiée (306). Si la priorité du déclencheur est élevée (310), le déclencheur est transmis (312). Si la priorité est basse (312), l’état de l’UE est vérifié (314). Si l’UE est connecté (316), le déclencheur d’appareil est transmis (310). Si l’UE est inactif (318), le déclencheur d’appareil est mis en tampon (320). Un compteur est ensuite incrémenté (322). Si le compteur a atteint sa valeur maximale, le déclencheur d’appareil est transmis (310). Sinon, le processus de vérification de l’état de l’UE est répété (314). LE compteur peur être fixé à toute valeur qui permet une transmission efficace de messages de déclenchement d’appareils. De suivre une telle procédure attend que l’UE de destination du message de déclenchement d’appareil se place de lui-même dans un état de connexion, avant d’obliger l’UE à passer dans un état de connexion pour recevoir le message de déclenchement d’appareil.
[0049] Sur la base des solutions indiquées ci-dessus, l’indicateur de Requête d’information d’État d’UE peut soit être contenue dans un message SIR (Requête d’informations d’Abonné) ou dans un nouveau message USIR (Requête d’information d’État Utilisateur). De même la SIA (Réponse d’informations Abonné) ou la nouvelle USIA (Réponse d’informations d’État Utilisateur) contiendra la réponse d’informations d’été d’UE présente.
[0050] SIR et SIA sont des messages existants définis au TS 29.336 de la 11e version de la norme 3GPP. Ces messages seront améliorés de manière à refléter les informations d’état d’UE suivantes. Le SIR comportera une nouvelle Paire Attribut/Valeur (PAV) pour l’indicateur de Requête d’informations d’état d’UE, le SIA comportera une nouvelle P AV pour la Réponse d’informations d’état d’UE. USIR et USIA sont de nouveaux messages qui seront définis par des documents ultérieurs.
[0051] Les informations d’État Utilisateur peuvent être l’un des états suivants de l’UE : [0052] DETACHED (Détaché) [0053] ATTACHED_NOT_REACHABLE_FOR_PAGING (Attaché, non accessible pour notification) [0054] ATT ACHED_REACH AB LE_F OR_P AGIN G (Attaché, accessible pour notification) [0055] CONNECTED_N OT_RE ACH ABLE_F OR_P AGIN G (Connecté, non accessible pour notification) [0056] CONNECTED_RE ACH AB LE_F OR_P AGIN G (Connecté, accessible pour notification) [0057] NETWORK_DETERMINED_NOT_REACHABLE (Déterminé inaccessible par le réseau) [0058] De nouvelles informations d’état peuvent également être ajoutées en cas de besoin. Par exemple : EMM_IDLE et EMM_CONNECTED. Le HSS peut ne pas connaître les informations d’état MM de l’UE. Dans cette éventualité, la procédure de notification du HSS peut être améliorée pour conserver d’autres informations d’état d’UE, comme UE MM, l’état SM, et ainsi de suite.
[0059] L’ organigramme de la FIG. 4 présente le fonctionnement d’un mode de réalisation dans lequel le MTC-IWF obtient l’état de l’UE depuis une Entité de Gestion Mobile (MME) [0060] Un Serveur de Capacité de Service (SCS) détermine la nécessité de déclencher l’appareil (402). Si le SCS ne possède pas les coordonnées d’un MTC-IWF, il peut en premier lieu déterminer la ou les adresse(s) IP et le(s) port(s) d’un MTC-IWF en effectuant une requête DNS en utilisant l’identifiant Externe ou au moyen d’un identifiant de MTC-IWF (404) configuré localement.
[0061] Le SCS transmet ensuite un message de Demande de Déclenchement d’Appareil au MTC-IWF (406). Le message peut contenir des informations telles que l’identifiant Externe ou le MSISDN, l’identifiant du SCS, le numéro de référence du déclencheur, la période de validité, la priorité, l’ID du port d’application, la charge du déclenchement, et ainsi de suite. Le SCS inclut une Charge de Déclenchement qui peut contenir les informations destinées à l’application du MTC, ainsi que les informations nécessaires à leur acheminement jusqu’à celle-ci.
[0062] Le MTC-IWF vérifie que le SCS est autorisé à transmettre des requêtes de déclenchement et qu’il n’a pas dépassé son quota ou son taux de soumission de déclenchements par Tsp (408). Si cette vérification échoue, le MTC-IWF transmet un message de Confirmation de Déclenchement d’Appareil contenant une valeur de cause indiquant la raison de la condition d’échec, et le flux s’interrompt à cette étape.
[0063] Le MTC-IWF transmet au HS S un message de Requête d’informations Abonné (Identifiant Externe ou MSISDN et Identifiant SCS) au HSS/HLR pour déterminer si le SCS est autorisé à déclencher l’UE, pour associer l’identifiant Externe ou le MSISDN au IMSI et recevoir les « Informations de Routage » enregistrées correspondantes, y compris les identités du ou des nœud(s) desservant TUE (410).
[0064] Le HSS/HLR envoie le message d’informations Abonné (IMSI ou MSISDN et « Informations de Routage » correspondantes incluant les identités du ou des nœud(s) desservant TUE) (412). La politique du HSS/HLR (pouvant dépendre de l’ID du VPLMN) peut avoir une influence sur les identités de nœuds en service retournées. Si la valeur de cause indique que le SCS n’est pas autorisé à transmettre un message de déclenchement à cet UE, ou s’il n’y a pas d’informations d’abonnement valides, le MTC-IWF renvoie un message de Confirmation de Déclenchement d’Appareil contenant une valeur de cause indiquant la raison de la condition d’échec et le flux s’interrompt à cette étape.
[0065] Le message de Requête d’informations d’État Utilisateur est envoyé au MME depuis le MTC-IWF, demandant l’état de l’UE (414). Les informations contenues dans ce message sont celles indiquées plus haut en explication de la FIG. 2.
[0066] Le message de Réponse d’informations Utilisateur est transmis en réponse à la requête du MME, l’informant de l’état de l’UE (416). Les informations contenues dans ce message sont encore une fois telles qu’indiqué plus haut en explication de la FIG. 2.
[0067] Le MTC-IWF décide à cette étape s’il doit mettre le message de déclenchement en tampon ou le délivrer, en utilisant la méthode détaillée ci-dessus en explication de la FIG. 3 (418). Une fois que le MTC-IWF a décidé d’envoyer le déclencheur, il sélectionne une procédure de livraison de déclencheur sur la base des informations reçues du HSS et des politiques locales. La procédure de livraison T5 est sélectionnée et le MTC-IWF tente une procédure de livraison de déclencheur T5.
[0068] L’organigramme de la FIG. 5 présente le fonctionnement d’un mode de réalisation dans lequel le MTC-IWF obtient l’état de l’UE depuis un Serveur de Présence.
[0069] Un Serveur de Capacité de Service (SCS) détermine la nécessité de déclencher l’appareil (502). Si le SCS ne possède pas les coordonnées d’un MTC-IWF, il peut en premier lieu déterminer la ou les adresse(s) IP et le(s) port(s) d’un MTC-IWF en effectuant une requête DNS en utilisant l’identifiant Externe ou au moyen d’un identifiant de MTC-IWF (504) configuré localement.
[0070] Le SCS transmet ensuite un message de Demande de Déclenchement d’Appareil au MTC-IWF (506). Le message peut contenir des informations telles que l’identifiant Externe ou le MSISDN, l’identifiant du SCS, le numéro de référence du déclencheur, la période de validité, la priorité, l’ID du port d’application, la charge du déclenchement, et ainsi de suite. Le SCS inclut une Charge de Déclenchement qui peut contenir les informations destinées à l’application du MTC, ainsi que les informations nécessaires à leur acheminement jusqu’à celle-ci.
[0071] Le MTC-IWF vérifie que le SCS est autorisé à transmettre des requêtes de déclenchement et qu’il n’a pas dépassé son quota ou son taux de soumission de déclenchements par Tsp (508). Si cette vérification échoue, le MTC-IWF transmet un message de Confirmation de Déclenchement d’Appareil contenant une valeur de cause indiquant la raison de la condition d’échec, et le flux s’arrête à cette étape.
[0072] Le MTC-IWF transmet au HSS un message de Requête d’informations Abonné (Identifiant Externe ou MSISDN et Identifiant SCS) au HSS/HLR pour déterminer si le SCS est autorisé à déclencher l’UE, pour associer l’identifiant Externe ou le MSISDN au IMSI et recevoir les « Informations de Routage » enregistrées correspondantes, y compris les identités du ou des nœud(s) desservant l’UE (510).
[0073] Le HSS/HLR envoie le message d’informations Abonné (IMSI ou MSISDN et « Informations de Routage » correspondantes incluant les identités du ou des nœud(s) desservant l’UE) (512). La politique du HSS/HLR (pouvant dépendre de l’ID du VPLMN) peut avoir une influence sur les identités de nœuds en service retournées. Si la valeur de cause indique que le SCS n’est pas autorisé à transmettre un message de déclenchement à cet UE, ou s’il n’y a pas d’informations d’abonnement valides, le MTC-IWF renvoie un message de Confirmation de Déclenchement d’Appareil contenant une valeur de cause indiquant la raison de la condition d’échec et le flux s’interrompt à cette étape.
[0074] Le message de Requête d’informations d’État Utilisateur est transmis au Serveur de Présence par le MTC-IWF, demandant l’état de l’UE (514). Les informations contenues dans ce message sont telles qu’indiqué plus haut. Le MTC-IWF peut être configuré au préalable avec l’adresse du serveur de présence. Cette étape peut s’effectuer en parallèle de 510.
[0075] Le message de Réponse d’informations d’état utilisateur est envoyé en réponse à la requête du Serveur de Présence, l’informant de l’état de l’UE (516). Les informations contenues dans ce message sont telles que décrit plus haut.
[0076] Le MTC-IWF décide à cette étape de mettre le message de déclenchement en tampon ou de le délivrer (518). Ceci peut être réalisé selon la méthode décrite plus haut, en explication de la FIG. 3. Quand le MTC-IWF a décidé de transmettre le déclencheur, le MTC-IWF tente la procédure de livraison de déclencheur T5 (520).
[0077] Dans certains modes de réalisation, le MTC-IWF peut être agencé de manière à communiquer directement avec l’UE et à conserver les informations d’état de l’UE. Dans ce cas, l’UE transmet directement les informations d’état au MTC-IWF et le mécanisme de découverte du MTC-IWF par l’UE peut être le même que celui de découverte du Serveur de Présence par l’UE. Dans certains modes de réalisation, le MTC-IWF et le Serveur de Présence peuvent être situés au même emplacement, ou implémentés dans le même boîtier. Dans un tel mode de réalisation, il n’est pas nécessaire d’implémenter toutes les fonctionnalités dans le même boîtier. En d’autres termes, il peut être possible d’implémenter une partie des fonctionnalités d’un Serveur de Présence dans le MTC-IWF.
[0078] L’organigramme de la FIG. 6, présente le fonctionnement d’un mode de réalisation dans lequel le MTC-IWF met en tampon le déclencheur dans le MME. Il convient de noter que le MME n’est indiqué qu’à titre d’exemple. Le nœud tampon pourrait également être SGSN ou MSC.
[0079] Un Serveur de Capacité de Service (SCS) détermine la nécessité de déclencher l’appareil (602). Si le SCS ne possède pas les coordonnées d’un MTC-IWF, il peut en premier lieu déterminer la ou les adresse(s) IP et le(s) port(s) d’un MTC-IWF en effectuant une requête DNS en utilisant l’identifiant Externe ou au moyen d’un identifiant de MTC-IWF (604) configuré localement.
[0080] Par la suite, le SCS envoie un message de demande de déclenchement de dispositif à la MTC-IWF (606). Le message peut contenir des informations comme un Identificateur Externe ou MSISDN, un Identificateur SCS, un numéro de référence de déclenchement, une période de validité, une priorité, une charge utile de déclenchement, et similaire. Le SCS comprend une charge utile de déclenchement qui peut contenir les informations destinées à l’application MTC, conjointement avec les informations pour la router vers l’application MTC.
[0081] La MTC-IWF vérifie que le SCS est autorisé à envoyer des demandes de déclenchement et que le SCS n’a pas dépassé son quota ou son taux de soumission de déclenchement sur Tsp (608). Si cette vérification échoue, la MTC-IWF envoie un message de confirmation de déclenchement de dispositif avec une valeur de cause indiquant la raison de la condition d’échec et le flux s’arrête à cette étape.
[0082] La MTC-IWF envoie un message de demande d’information abonné (Identificateur Externe ou MSISDN et Identificateur SCS) au HSS/HLR pour déterminer si le SCS est autorisé à déclencher l’EU, résoudre l’Identificateur Externe ou MSISDN en IMSI et récupérer les “informations de Routage” stockées HSS connexes comprenant les identités du(des) nœud(s) CN serveur(s) de l’EU (610).
[0083] Le HSS/HLR envoie le message de réponse d’information abonné (IMSI et/ou MSISDN et les “informations de Routage” connexes comprenant les identités de nœud(s) serveur(s), la cause) (612). La politique HSS/HLR (éventuellement dépendante de PID VPLMN) peut influencer quelles identités de nœud serveur sont retournées. Si la valeur de cause indique que le SCS n’est pas autorisé à envoyer un message déclencheur à cet EU, ou qu’il n’y a pas d’information de souscription valide, la MTC-IWF envoie un message de confirmation de déclenchement de dispositif avec une valeur de cause indiquant la raison de la condition d’échec et le flux s’arrête à cette étape.
[0084] La MTC-IWF utilise les capacités d’EU, les capacités de nœud(s) de Réseau Cœur (CN) récupérées depuis le HSS pour sélectionner un nœud CN serveur approprié capable de déclenchement T5 (614). La MTC-IWF envoie une demande de soumission au nœud CN serveur. La demande de soumission peut contenir une IMSI, une priorité de message, un ID MTC-IWF, un numéro de référence, un drapeau de tentative de remise unique (optionnel), un temps de validité (optionnel), un type de demande (application de déclenchement), une PDU d’application. S’il y a plus d’un nœud CN serveur, la MTC-IWF devrait envoyer le message au nœud CN serveur où l’EU est actuellement mis en attente avec la plus haute probabilité. Cela pourrait être, par exemple, sur la base d’informations reçues du HSS ou d’informations mises en cache à partir de tentatives de déclenchement précédentes.
[0085] Le nœud CN serveur indique le type de demande (application de déclenchement), la PDU d’application, l’ID MTC-IWF, le numéro de référence à l’intérieur du message NAS et les remet à l’EU (616). Le nœud CN serveur génère les informations CDR nécessaires (618). L’EU fournit le contenu de déclenchement et le type de déclenchement à l’application correspondante (620).
[0086] Si l’EU est en mode de repos, le nœud CN serveur peut appeler par radiomessagerie l’EU avant d’envoyer un message NAS pour la remise du déclencheur (622). Si l’EU n’est pas en mode de repos, il remet le déclencheur (624).
[0087] Si l’EU est en mode de repos, la MME décide si mettre en mémoire tampon le message déclencheur ou le remettre. Cela peut être accompli selon un procédé détaillé plus loin sur la Fig. 7 ou d’une variété d’autres façons différentes.
[0088] Le nœud CN serveur envoie un message de rapport de remise à la MTC-IWF (626). Le rapport de remise peut contenir plusieurs éléments d’information, comprenant l’IMSI, la cause, le numéro de référence, remis par le nœud CN, le type de réponse (application de déclenchement), et si reçues, la PDU d’application, des informations concernant la mise en mémoire tampon dans la MME). La cause indique si le message déclencheur a été remis avec succès à l’EU ou s’il a été mis en mémoire tampon, ou s’il a échoué, la raison de l’échec.
[0089] La MTC-IWF envoie ensuite un rapport au SCS l’informant des actions engagées (628).
[0090] En référence à la FIG. 7, un organigramme illustrant le comportement de la MME en fonction du statut de l’EU. Après la réception du déclencheur (702), la MME vérifie l’état de l’EU (704). La priorité du déclencheur de dispositif est ensuite vérifiée (706). Si le déclencheur de dispositif est haut (708), alors le déclencheur de dispositif est remis (710). Si la priorité est basse (712), alors l’état de l’EU est vérifié (714). Si l’EU est connecté (716), alors le déclencheur de dispositif est remis (710). Si l’EU est au repos (718), alors le déclencheur de dispositif est mis en mémoire tampon dans la MME (720). Ensuite un compteur est incrémenté (722). Si le compteur a atteint sa quantité maximale, le déclencheur de dispositif est remis (710). Sinon, le processus de vérification de l’état de l’EU est répété (714). Le compteur peut être réglé pour être un nombre quelconque qui permettrait la transmission efficace de messages déclencheurs de dispositif. Suivre une telle procédure attend que l’EU de destination du message déclencheur de dispositif passe d’un état de repos à un connecté tout seul, sans forcer l’EU à entrer dans l’état connecté pour recevoir le message déclencheur de dispositif.
[0091] Les exemples suivants se rapportent à des modes de réalisation supplémentaires.
[0092] Une fonction d’interfonctionnement de communications de type machine (MTC-IWF) dans un réseau LTE peut comprendre : un processeur conçu pour : recevoir une demande de déclenchement de dispositif via le réseau LTE ; valider la demande de déclenchement de dispositif ; demander une information de statut d’un équipement utilisateur (EU) auquel le déclencheur de dispositif doit être envoyé ; recevoir l’information de statut de TEU ; et envoyer le déclencheur de dispositif en se basant sur l’information de statut ; dans laquelle l’information de statut comprend une information sur le statut de connexion de l’EU. L’information de statut peut indiquer si TEU est dans un état de repos-ou dans un état connecté. La MTC-IWF peut en outre être conçue pour : déterminer la priorité de la demande de déclenchement de dispositif et envoyer le message déclenchement de dispositif lorsque la priorité de la demande de déclenchement de dispositif est haute. La MTC-IWF peut en outre être conçue pour : déterminer la priorité de la demande de déclenchement de dispositif ; et lorsque la priorité de la demande de déclenchement de dispositif est basse : envoyer la demande de déclenchement de dispositif lorsque TEU est dans un état connecté ; et mettre la demande de déclenchement de dispositif en mémoire tampon lorsque TEU est dans un état de repos.
[0093] Dans un autre mode de réalisation, un procédé pour envoyer un message déclencheur de dispositif à un équipement utilisateur (EU) de destination dans un réseau LTE peut comprendre : la réception d’une demande pour envoyer un message déclencheur de dispositif ; la détermination de la priorité du message déclencheur de dispositif ; la transmission du message déclencheur de dispositif si la priorité du message déclencheur de dispositif est haute ; si la priorité du message déclencheur de dispositif est basse, la vérification de si TEU de destination pour le message déclencheur de dispositif est dans un état connecté ; l’envoi du message déclencheur de dispositif lorsque TEU de destination est dans un état connecté ; sinon la mise en mémoire tampon du message déclencheur de dispositif jusqu’à ce que TEU de destination soit dans un état connecté.
[0094] Dans un mode de réalisation, le procédé est réalisé par une fonction d’interfonctionnement de communications de type machine (MTC-IWF). Dans un mode de réalisation, le procédé est réalisé par une entité de gestion mobile (MME).
[0095] Dans un autre mode de réalisation, un procédé pour envoyer un message déclencheur de dispositif dans un réseau LTE peut comprendre : la réception d’une demande de déclenchement de dispositif ; la validation de la demande de déclenchement de dispositif ; la demande d’une information de statut de l’équipement utilisateur (EU) auquel le déclencheur de dispositif doit être envoyé ; la réception de l’information de statut de PEU ; et l’envoi du déclencheur de dispositif en se basant sur l’information de statut ; dans lequel l’information de statut comprend une information sur le statut de connexion de l’EU.
[0096] Dans un mode de réalisation, l’information de statut indique si l’EU est dans un état de repos ou dans un état connecté.
[0097] Dans un mode de réalisation, l’envoi du déclencheur de dispositif basé sur l’information de statut comprend : la détermination de la priorité de la demande de déclenchement de dispositif ; et l’envoi du message déclencheur de dispositif lorsque la priorité de la demande de déclenchement de dispositif est haute.
[0098] Dans un mode de réalisation, l’envoi du déclencheur de dispositif basé sur l’information de statut comprend : la détermination de la priorité de la demande de déclenchement de dispositif ; et lorsque la priorité de la demande de déclenchement de dispositif est basse : l’envoi de la demande de déclenchement de dispositif lorsque l’EU est dans un état connecté ; et la mise en mémoire tampon de la demande de déclenchement de dispositif lorsque l’EU est dans un état de repos. Dans un mode de réalisation, la mise en mémoire tampon de la demande de déclenchement de dispositif est réalisée par une entité de gestion mobile (MME).
[0099] Dans un mode de réalisation, le procédé peut comprendre en outre : la création d’un rapport détaillant l’envoi du déclencheur de dispositif ; et la création d’un enregistrement de données de charge (CDR) basé sur l’envoi du déclencheur de dispositif.
[00100] Dans un mode de réalisation, le procédé est réalisé par une fonction d’interfonctionnement de communications de type machine (MTC-IWF).
[00101] Dans un mode de réalisation, la demande d’information de statut de l’équipement utilisateur (EU) auquel le déclencheur de dispositif doit être envoyé peut comprendre l’envoi d’un message de demande d’information d’abonné (SIR) à un serveur d’abonné résidentiel (HSS) ; et la réception de l’information de statut de l’EU peut comprendre la réception d’un message de réponse d’information abonné (SIA) provenant du HSS.
[00102] Dans un mode de réalisation, le message SIR comprend une demande d’information d’état de l’EU ; et le message SIA peut comprendre une information d’état de l’EU.
[00103] Dans un mode de réalisation, l’information d’état comprend une information indiquant si l’EU est dans un état de repos ou dans un état connecté.
[00104] Dans un mode de réalisation, l’information d’état est choisie parmi les suivantes : séparé, Joint_Non_Accessible_Pour_Radiomessagerie
Joint_Accessible_Pour_Radiomessagerie Connecté_Non_accessible-Pour_Radiomessagerie Connecté_accessible_Pour_Radiomessagerie et Réseau_Déterminé_Comme non accessible.
[00105] Dans un mode de réalisation, la demande d’information de statut de l’équipement utilisateur (EU) auquel le déclencheur de dispositif doit être envoyé peut comprendre l’envoi d’un message de demande d’information abonné (SIR) à une entité de gestion mobile (MME) ; et la réception de l’information de statut de l’EU comprend la réception d’un message de réponse d’information abonné (SIA) de la MME.
[00106] Dans un mode de réalisation, la demande d’information de statut de l’équipement utilisateur (EU) auquel le déclencheur de dispositif doit être envoyé comprend l’envoi d’un message de demande d’information abonné (SIR) à un serveur de présence ; et la réception de l’information de statut de PEU comprend la réception d’un message de réponse d’information abonné (SIA) provenant du serveur de présence.
[00107] Dans un mode de réalisation, la demande d’information de statut de l’équipement utilisateur (EU) auquel le déclencheur de dispositif doit être envoyé peut comprendre l’envoi d’un message de demande d’information abonné (SIR) à un serveur d’abonné résidentiel (HSS) ; et la réception de l’information de statut de l’EU comprend la réception d’un message de réponse d’information abonné (SIA) provenant du HSS.
[00108] Dans un autre mode de réalisation, un procédé peut comprendre : la réception d’une demande de déclenchement de dispositif ; la validation de la demande de déclenchement de dispositif ; la demande d’une information de statut de l’équipement utilisateur (EU) auquel le déclencheur de dispositif doit être envoyé ; la réception de l’information de statut de l’EU ; et la soumission d’une demande à une entité de gestion mobile pour traiter la demande de déclenchement de dispositif.
[00109] Dans un mode de réalisation, le procédé est réalisé par une fonction d’interfonctionnement de communications de type machine (MTC-IWF).
[00110] Bien que certaines caractéristiques de l’invention aient été illustrées et décrites ici, de nombreuses modifications, substitutions, changements, et équivalents peuvent venir à l’esprit de l’homme du métier. Il convient, par conséquent, de comprendre que les revendications annexées sont destinées à couvrir toutes ces modifications et changements comme entrant dans la portée de l’invention.

Claims (18)

  1. Revendications
    1. Fonction d’interfonctionnement de communications de type machine (MTC-IWF) dans un réseau d’évolution à long terme (LTE) comprenant : un processeur conçu pour : recevoir une demande d’envoi d’un message déclencheur de dispositif via le réseau LTE ; valider la demande d’envoi d’un message déclencheur de dispositif ; demander une information de statut d’un équipement utilisateur (EU) auquel le message déclencheur de dispositif doit être envoyé ; recevoir l’information de statut de l’EU ; déterminer une priorité de la demande d'envoi du message déclencheur de dispositif; et envoyer le message déclencheur de dispositif en se basant sur . l’information de statut lorsque la priorité,de la demande d'envoi du message déclencheur de dispositif est haute, dans laquelle, lorsque la priorité de la demande du déclencheur de priorité est basse, envoyer le message déclencheur de dispositif lorsque l'EU est dans un état connecté; et mettre en mémoire tampon le message déclencheur de dispositif lorsque l'EU est à l'état de repos, dans lequel l'information de statut comprend l'information relative au statut de la connexion de l'EU.
  2. 2. Une méthode pour envoyer un message déclencheur de dispositif à destination d'un équipement utilisateur (EU) dans un réseau LTE comprenant; recevoir une demande d'envoi d'un message déclencheur de dispositif; déterminer une priorité du message déclencheur de dispositif; transmettre le message déclencheur de dispositif si la priorité du message déclencheur de dispositif est haute; le cas non échéant, mettre en mémoire tampon le message déclencheur de dispositif jusqu'à ce que l'EU de destination soit dans un état connecté.
  3. 3. La méthode selon la revendication 2, dans laquelle la méthode est exécutée par une fonction d’interfonctionnement de communications de type machine (MTC-IWF).
  4. 4. La méthode selon la revendication 2, dans laquelle la méthode est exécutée par une entité de gestion mobile (MME).
  5. 5. Une méthode d’envoi de message déclencheur de dispositif dans un réseau d’évolution à long terme (LTE) comprenant: recevoir une demande d’envoi d’un message déclencheur de dispositif ; valider la demande d’envoi du message déclencheur de dispositif ; demander une information de statut de l’équipement utilisateur (EU) auquel le message déclencheur de dispositif doit être envoyé ; recevoir ,l'information de .statut de l’EU auquel le message, déclencheur de dispositif doit être envoyé ; déterminer la priorité de la demande d'envoi du message déclencheur de dispositif ; envoyer le message déclencheur de dispositif en se basant sur l’information de statut lorsque la priorité de la demande d'envoi du message déclencheur de dispositif est haute; selon laquelle, lorsque la priorité de la demande de déclenchement de dispositif est basse : envoyer le message déclencheur de dispositif lorsque l'EU est dans un état de repos; et mettre en mémoire tampon le message déclencheur de dispositif lorsque l'EU est à l'état de repos, dans laquelle l'information de statut comprend l'information relative au statut de la connexion de l'EU.
  6. 6. La méthode selon la revendication 5, dans lequel la mise en mémoire tampon du message déclencheur de dispositif est réalisée par une entité de gestion mobile (MME).
  7. 7. La méthode selon la revendication 5, comprenant en outre: créer un rapport détaillant l'envoi du message déclencheur de dispositif; et créer un enregistrement de données de chargement (CDR) basé sur l'envoi du déclencheur de dispositif.
  8. 8. La méthode selon la revendication 5, dans laquelle la méthode est exécutée par une fonction d’interfonctionnement de communications de type machine (MTC-IWF)
  9. 9. La méthode selon la revendication 8, dans laquelle: on demande l'information de statut de l'équipement utilisateur (EU) auquel le message déclencheur de dispositif doit être envoyé comprenant l'envoi d'un message de demande d’information d’abonné (SIR) à un Serveur d'abonné résidentiel (HSS): et on reçoit l'information de statut de l'EU auquel le message déclencheur de dispositif doit être envoyé comprenant la réception d'un message de Réponse d'informations d'Abonné (SIA) du HSS.
  10. 10. La méthode de la revendication 9, dans laquelle le message SIR comprend une demande d'information d'état de L'EU; et en outre, dans laquelle le message SIA comprend une information d'état de l'EU.
  11. 11. La méthode selon la revendication 108, dans laquelle l'information d'état comprend l'information quant au fait que l'EU est dans un état de repos ou dans un état connecté.
  12. 12. La méthode selon la revendication 11, selon laquelle l'information d'état est sélectionnée parmi les informations suivantes : Détaché, Attaché_Pas_accessible_Pour_Pagination, Attaché_Accessible_Pour_Pagination, Connecté_Non_Accessible_Pour_Pagination, Connecté_Accessible_Pour_Pagination et Réseau_Déterminé_Non_Accessible.
  13. 13. La méthode selon la revendication 9, dans laquelle: le message SIR est un message de demande d’information d’état utilisateur (USIR) ; et le message SIA est un message de réponse d’information d’état utilisateur (USIA).
  14. 14. Procédé selon la revendication 8, dans laquelle : la demande d’information de statut de l’équipement utilisateur (EU) auquel le message déclencheur de dispositif doit être envoyé comprend l’envoi d’un message de demande d’information d’abonné (SIR) à une entité de gestion mobile (MME); et la réception de l'information de statut de l'EU comprend la réception d’un message de réponse d’information abonné (SIA) provenant de la MME.
  15. 15. La méthode selon la revendication 8, dans laquelle : la demande d’information de statut de l’équipement utilisateur (EU) auquel le message déclencheur de dispositif doit être envoyé comprend l’envoi d’un message de demande d’information d’abonné (SIR) à un Serveur de Présence; et la réception de l’information de statut de l’EU comprend la réception d’un message de réponse d’information abonné (SIA) provenant du Serveur de Présence.
  16. 16. La méthode selon la revendication 8, dans laquelle: la demande d'information de statut de l'équipent utilisateur (EU) auquel le message déclencheur de dispositif doit être envoyé comprend l'envoi d'un message de demande d’information d’abonné (SIR) à un Serveur d'abonné résidentiel (HSS); et la réception de l'information de statut de l'EU comprend la réception d'une réponse d’informations d'abonné (SIA) provenant de l'HSS.
  17. 17. La méthode selon la revendication 5, comprenant en outre: la soumission d'une demande à une entité de gestion mobile de traiter la demande d'envoi d'un message déclencheur de dispositif.
  18. 18. La méthode de la revendication 17, dans laquelle : la méthode est exécutée par une fonction d’interfonctionnement de communications de type machine (MTC-IWF).
BE2013/0464A 2012-07-02 2013-07-02 Appareil et procede pour envoyer efficacement des messages de declenchement d'appareil. BE1022333B1 (fr)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201261667325P 2012-07-02 2012-07-02
WO61/667325 2012-07-02
US61/667325 2012-07-02
US13/755,166 US8989070B2 (en) 2012-07-02 2013-01-31 Apparatus and method to efficiently send device trigger messages
PCT/US2013/046564 WO2014007990A1 (fr) 2012-07-02 2013-06-19 Appareil et procédé pour la transmission efficace de messages de déclenchement de dispositif

Publications (1)

Publication Number Publication Date
BE1022333B1 true BE1022333B1 (fr) 2016-03-16

Family

ID=74556583

Family Applications (1)

Application Number Title Priority Date Filing Date
BE2013/0464A BE1022333B1 (fr) 2012-07-02 2013-07-02 Appareil et procede pour envoyer efficacement des messages de declenchement d'appareil.

Country Status (17)

Country Link
US (2) US8989070B2 (fr)
EP (2) EP3142392B1 (fr)
JP (2) JP5950244B2 (fr)
KR (2) KR101657443B1 (fr)
CN (2) CN107493159B (fr)
BE (1) BE1022333B1 (fr)
BR (1) BR112014030156A2 (fr)
CA (1) CA2874475A1 (fr)
ES (2) ES2733753T3 (fr)
FI (4) FI3142392T3 (fr)
FR (1) FR2992820B1 (fr)
HU (1) HUE043858T2 (fr)
IT (1) ITMI20131103A1 (fr)
NL (1) NL2011078C2 (fr)
SE (1) SE1350812A1 (fr)
TW (3) TWI489893B (fr)
WO (1) WO2014007990A1 (fr)

Families Citing this family (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8989070B2 (en) 2012-07-02 2015-03-24 Intel Corporation Apparatus and method to efficiently send device trigger messages
KR20140022669A (ko) * 2012-08-14 2014-02-25 한국전자통신연구원 다중 전송경로를 제공하는 사물지능통신 시스템 및 그 구동 방법
US8923880B2 (en) 2012-09-28 2014-12-30 Intel Corporation Selective joinder of user equipment with wireless cell
JP5997389B2 (ja) * 2012-10-01 2016-09-28 エルジー エレクトロニクス インコーポレイティド 無線通信システムにおける装置トリガー／スモールデータの交替／回収方法及び装置
WO2014097572A1 (fr) * 2012-12-21 2014-06-26 日本電気株式会社 Entité mtc-iwf, entité scs, procédé de signalisation, et support pouvant être lu par un ordinateur
WO2014109988A2 (fr) * 2013-01-08 2014-07-17 Ingterdigital Patent Holdings, Inc. Procédé et appareil pour déclencher des dispositifs et fournir des petites données
JP6319100B2 (ja) * 2013-01-11 2018-05-09 日本電気株式会社 メッセージ配信システム、配信順序決定装置、配信順序決定方法及び配信順序決定プログラム
CN111726234B (zh) * 2013-07-24 2023-03-24 康维达无线有限责任公司 服务域收费系统和方法
CN104704867B (zh) 2013-08-15 2018-10-30 华为技术有限公司 数据路由的方法和设备
US9301083B2 (en) 2014-01-06 2016-03-29 Intel IP Corporation Techniques for communication between service capability server and interworking function for device trigger recall/replace
EP3097740B1 (fr) 2014-01-24 2018-07-25 Sony Corporation Dispositif de communication
US20170019749A1 (en) * 2014-02-04 2017-01-19 Ntt Docomo, Inc. Service control system, user apparatus, and service control method
GB2539363A (en) 2014-06-12 2016-12-21 Nec Corp Communication system
EP3280175A4 (fr) * 2015-03-31 2018-03-28 NTT DoCoMo, Inc. Dispositif de passerelle et procédé de communication
CN106604251A (zh) * 2015-10-20 2017-04-26 上海中兴软件有限责任公司 一种触发消息处理方法、装置和系统
US10129689B2 (en) 2015-11-02 2018-11-13 Definition Networks, Inc. Systems and methods for machine-type communication
US11297153B2 (en) * 2016-03-22 2022-04-05 At&T Mobility Ii Llc Evolved packet core applications microservices broker
CN109417728B (zh) * 2016-06-30 2023-02-28 苹果公司 用于授权和启用/禁用增强覆盖功能的装置
EP3310104A4 (fr) * 2016-08-10 2018-06-20 LG Electronics Inc. -1- Procédé de réception de signal de radiorecherche dans un nb-iot et procédé de réalisation d'une procédure d'accès aléatoire dans un nb-iot
US10911936B2 (en) 2016-10-07 2021-02-02 Nec Corporation SCEF entity, communication terminal, data processing method, data receiving method, and non-transitory computer readable medium
DE102017200100B3 (de) * 2017-01-05 2018-03-15 Volkswagen Aktiengesellschaft Verfahren zur kollektiven Erfassung von Daten in einem Mobilfunknetz sowie Datenerfassungsrechner und Mobilfunknetz-Verwaltungseinheit zur Verwendung bei dem Verfahren
US10530599B2 (en) 2017-02-27 2020-01-07 Oracle International Corporation Methods, systems and computer readable media for providing service capability exposure function (SCEF) as a cloud service
US10506403B2 (en) 2017-02-27 2019-12-10 Oracle International Corporation Methods, systems and computer readable media for providing integrated service capability exposure function (SCEF), service capability server (SCS) and application server (AS) services
US10405158B2 (en) 2017-02-27 2019-09-03 Oracle International Corporation Methods, systems and computer readable media for providing service capability exposure function (SCEF) as a diameter routing agent (DRA) feature
US10075827B1 (en) 2017-03-07 2018-09-11 At&T Intellectual Proprety I, L.P. System and method for machine to machine subscriber information and retrieval protection
US10820192B2 (en) * 2017-06-16 2020-10-27 Huawei Technologies Co., Ltd. Downlink transmission in a RAN inactive mode
US10448449B2 (en) 2017-07-13 2019-10-15 Oracle International Corporation Methods, systems, and computer readable media for dynamically provisioning session timeout information in a communications network
US10334419B2 (en) 2017-08-16 2019-06-25 Oracle International Corporation Methods, systems, and computer readable media for optimizing machine type communication (MTC) device signaling
US10313883B2 (en) 2017-11-06 2019-06-04 Oracle International Corporation Methods, systems, and computer readable media for using authentication validation time periods
CN109996302A (zh) * 2018-01-02 2019-07-09 中国移动通信有限公司研究院 一种SGsMSC的选择方法、装置及设备
US11218468B2 (en) * 2018-03-06 2022-01-04 T-Mobile Usa, Inc. MSISDN request handling for identity fraud management
US11146577B2 (en) 2018-05-25 2021-10-12 Oracle International Corporation Methods, systems, and computer readable media for detecting and mitigating effects of abnormal behavior of a machine type communication (MTC) device
US10616802B2 (en) 2018-09-04 2020-04-07 Oracle International Corporation Methods, systems and computer readable media for overload and flow control at a service capability exposure function (SCEF)
US11381955B2 (en) 2020-07-17 2022-07-05 Oracle International Corporation Methods, systems, and computer readable media for monitoring machine type communications (MTC) device related information
US11700510B2 (en) 2021-02-12 2023-07-11 Oracle International Corporation Methods, systems, and computer readable media for short message delivery status report validation

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004040651A (ja) * 2002-07-05 2004-02-05 Ntt Docomo Inc 通信方法、通信装置、端末装置及び通信サービス提供サーバ
KR100547734B1 (ko) 2003-06-13 2006-01-31 삼성전자주식회사 직교 주파수 분할 다중 방식을 사용하는 이동 통신시스템에서 매체 접속 제어 계층의 동작 상태 제어 방법
KR20050029254A (ko) 2003-09-20 2005-03-24 삼성전자주식회사 광대역 무선 통신시스템의 슬리핑 스테이트에서 모드간의상태 천이를 위한 웨이크업 채널 전송 장치 및 방법
US8077683B2 (en) 2005-11-03 2011-12-13 Interdigital Technology Corporation Method and system for performing peer-to-peer communication between stations within a basic service set
US7912491B2 (en) * 2006-10-10 2011-03-22 Intel Corporation Techniques to efficiently transmit control messages to idle and sleep mode users in OFDMA based wireless networks
US8577363B2 (en) 2008-07-14 2013-11-05 Nokia Corporation Setup of device-to-device connection
DE102008040521A1 (de) * 2008-07-18 2010-01-21 Robert Bosch Gmbh Verfahren zur Herstellung eines Bauelements, Verfahren zur Herstellung einer Bauelementanordnung, Bauelement und Bauelementanordnung
KR101561063B1 (ko) * 2009-02-24 2015-10-19 삼성전자주식회사 펨토 셀을 포함하는 무선 통신 네트워크에서의 ｌｂｏ 서비스 지원 방법 및 장치
CN102696267B (zh) * 2009-11-25 2016-08-10 交互数字专利控股公司 机器类通信预注册
CN102652412B (zh) * 2010-02-08 2016-03-02 上海贝尔股份有限公司 一种用于在机器对机器通信系统中进行数据传输的方法及其设备
KR101609580B1 (ko) * 2010-02-10 2016-04-07 삼성전자주식회사 무선 통신 시스템 및 그의 사용자 단말기와 이동성 관리 엔티티 간 연결 방법
EP2537323B1 (fr) * 2010-02-15 2016-08-24 Telefonaktiebolaget LM Ericsson (publ) Déclenchement de dispositif de communication entre machines à l'aide d'un identifiant de ressource uniforme de protocole d'ouverture de session
US8639772B2 (en) * 2010-02-16 2014-01-28 Iboard Incorporated Centralized application resource manager
JP5490227B2 (ja) * 2010-04-30 2014-05-14 三菱電機株式会社 移動体通信システム
US9521621B2 (en) 2010-06-02 2016-12-13 Qualcomm Incorporated Application-proxy support over a wireless link
IN2012CN10350A (fr) * 2010-06-15 2015-07-31 Tekelec Inc
JP5732753B2 (ja) * 2010-06-23 2015-06-10 ソニー株式会社 無線通信装置、無線通信システムおよび無線通信方法
GB2485348A (en) * 2010-11-08 2012-05-16 Wireless Tech Solutions Llc Controlling communication from and/or to a mobile communications device in accordance with a relative priority indicated by the type of data packets
GB2485232B (en) * 2010-11-08 2015-02-04 Sca Ipla Holdings Inc Mobile communications network and method
KR101489108B1 (ko) * 2010-12-21 2015-02-02 코닌클리즈케 케이피엔 엔.브이. 원격통신 네트워크에서 서비스 요청을 처리하기 위한 방법 및 시스템
KR101746668B1 (ko) 2010-12-21 2017-06-13 한국전자통신연구원 접속해제 상태의 사물통신 디바이스를 위한 데이터 전송 방법 및 이를 이용하는 이동통신 시스템
EP2490463B1 (fr) * 2011-02-16 2015-12-16 HTC Corporation Réseaux de service et procédés pour la manipulation de déclenchement de dispositif de communication de type machine
GB2476415B (en) * 2011-03-23 2011-11-16 Renesas Mobile Corp Method and apparatus for facilitating machine-type communication
GB2496179B (en) * 2011-11-04 2014-01-22 Renesas Mobile Corp Reducing signaling Overhead in Wireless Communications Networks
US9210645B2 (en) * 2012-05-18 2015-12-08 Industrial Technology Reseach Institute Method for dynamically controlling data paths, MTC gateway and network device using the same
US8989070B2 (en) 2012-07-02 2015-03-24 Intel Corporation Apparatus and method to efficiently send device trigger messages

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
3GPP: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture Enhancements to facilitate communications with Packet Data Networks and Applications; (Release 11)", 3GPP DRAFT; 23682-010-CL, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, 2 December 2011 (2011-12-02), XP050575130 *
KOREA TELECOM: "Device triggering during suppression", 3GPP DRAFT; S2-113350_S2_86_DEVICE_TRIGGERING_DURING_SUPPRESSION_V2.2, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG2, no. Naantali; 20110711, 5 July 2011 (2011-07-05), XP050548629 *
SIERRA WIRELESS: "Solution for MTC Device Trigger indication from MTC Server", 3GPP DRAFT; S2-111038_O0295_DEVICE_TRIGGER_SOLUTION, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG2, no. Salt Lake City; 20110221, 26 February 2011 (2011-02-26), XP050524100 *

Also Published As

Publication number Publication date
NL2011078A (en) 2014-01-06
ITMI20131103A1 (it) 2014-01-03
ES2733753T3 (es) 2019-12-02
EP3142392A1 (fr) 2017-03-15
FI20135725A (fi) 2014-01-03
CN107493159B (zh) 2020-11-10
US20140003313A1 (en) 2014-01-02
KR20160036091A (ko) 2016-04-01
TW201724886A (zh) 2017-07-01
FR2992820A1 (en) 2014-01-03
FI20185380A (fi) 2018-04-23
FR2992820B1 (fr) 2016-11-25
FI20236300A1 (en) 2023-11-24
JP2015523028A (ja) 2015-08-06
EP2868009A4 (fr) 2016-02-24
CA2874475A1 (fr) 2014-01-09
CN107493159A (zh) 2017-12-19
TWI610582B (zh) 2018-01-01
WO2014007990A1 (fr) 2014-01-09
HUE043858T2 (hu) 2019-09-30
KR101618497B1 (ko) 2016-05-04
TW201528845A (zh) 2015-07-16
US9432150B2 (en) 2016-08-30
TWI568291B (zh) 2017-01-21
BR112014030156A2 (pt) 2017-06-27
TW201410051A (zh) 2014-03-01
ES2447340R1 (es) 2014-12-26
US20150249958A1 (en) 2015-09-03
EP2868009B1 (fr) 2019-05-15
CN103763694B (zh) 2017-08-29
US8989070B2 (en) 2015-03-24
JP2016184950A (ja) 2016-10-20
EP3142392B1 (fr) 2023-08-23
CN103763694A (zh) 2014-04-30
ES2447340B2 (es) 2015-09-29
JP5950244B2 (ja) 2016-07-13
FI127414B (en) 2018-05-31
FI3142392T3 (fi) 2023-09-06
TWI489893B (zh) 2015-06-21
KR101657443B1 (ko) 2016-09-19
SE1350812A1 (sv) 2014-01-03
KR20150008438A (ko) 2015-01-22
EP2868009A1 (fr) 2015-05-06
ES2447340A2 (es) 2014-03-11
NL2011078C2 (en) 2014-11-24

Similar Documents

Publication Publication Date Title
BE1022333B1 (fr) Appareil et procede pour envoyer efficacement des messages de declenchement d&#39;appareil.
US10070343B2 (en) Mobile device traffic management
FR2994357A1 (fr) Titre non renseigne
US20220385741A1 (en) Discovery of a Collaborative Proxy Node in a 3GPP Communication Network
US10382981B2 (en) Cellular network protocol optimizations
US20240089844A1 (en) Providing slice attribute information to user equipment in a mobile network environment
EP3753203B1 (fr) Procédés, système, ue, pgw-u et mme pour gérer une différenciation de trafic
US20230262098A1 (en) Packet flow descriptor provisioning
WO2020164226A1 (fr) Procédé et appareil de détection de trafic
US20240040375A1 (en) Providing an operator-encrypted partial user equipment route selection policy to user equipment

Legal Events

Date Code Title Description
PD Change of ownership

Owner name: APPLE INC.; US

Free format text: DETAILS ASSIGNMENT: CHANGE OF OWNER(S), CESSION

Effective date: 20200429