[go: nahoru, domu]

EP2324616A1 - Session initiation for device-to-device communication - Google Patents

Session initiation for device-to-device communication

Info

Publication number
EP2324616A1
EP2324616A1 EP08804099A EP08804099A EP2324616A1 EP 2324616 A1 EP2324616 A1 EP 2324616A1 EP 08804099 A EP08804099 A EP 08804099A EP 08804099 A EP08804099 A EP 08804099A EP 2324616 A1 EP2324616 A1 EP 2324616A1
Authority
EP
European Patent Office
Prior art keywords
session initiation
local
control plane
message
communication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP08804099A
Other languages
German (de)
French (fr)
Inventor
Klaus Franz Doppler
Mika Petri Olavi Rinne
Carl Simon Wijting
Cássio Barboza RIBEIRO
Klaus Hugl
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Oyj
Original Assignee
Nokia Oyj
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 Nokia Oyj filed Critical Nokia Oyj
Publication of EP2324616A1 publication Critical patent/EP2324616A1/en
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/14—Direct-mode setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/30—Managing network names, e.g. use of aliases or nicknames
    • 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/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/30—Types of network names
    • H04L2101/385—Uniform resource identifier for session initiation protocol [SIP URI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/18—Interfaces between hierarchically similar devices between terminal devices

Definitions

  • the present invention generally relates to session initiation for device-to-device communication.
  • the present invention relates to session initiation for device-to-device communication in a broadband radio access network environment.
  • radio communication systems such as mobile communication systems (like for example GSM (Global System for Mobile Communication) , GPRS (General Packet Radio Service) , UMTS (Universal Mobile Telecommunication System) or the like), efforts are made for an evolution of the radio access part thereof.
  • the evolution of radio access networks like for example the GSM EDGE radio access network (GERAN) and the Universal Terrestrial Radio Access Network (UTRAN) or the like
  • GERAN GSM EDGE radio access network
  • UTRAN Universal Terrestrial Radio Access Network
  • improved radio access networks are sometimes denoted as evolved radio access networks (like for example the Evolved Universal Terrestrial Radio Access Network (E- UTRAN) ) or as being part of a long-term evolution (LTE) .
  • E- UTRAN Evolved Universal Terrestrial Radio Access Network
  • LTE long-term evolution
  • LTE Long-Term Evolution according to 3GPP terminology
  • any kind of radio access network may likewise be applicable, as long as it exhibits comparable features and characteristics as described hereinafter.
  • FIG. 1 shows the architecture of an E-UTRAN system according to Release 8.
  • the E-UTRAN system includes eNBs (EUTRAN Node B' s or evolved Node B's), providing the
  • the eNBs may be interconnected with each other by means of an X2 interface (X2 Application Protocol) .
  • the eNBs are also connected by means of an Sl interface (Sl Application Protocol) to an evolved packet core network, more specifically to a mobility management entity (MME) by means of an Sl-MME interface, as well as to a serving gateway (S-GW) by means of an Sl-U interface.
  • MME mobility management entity
  • S-GW serving gateway
  • FIG. 2 shows the architecture of the E-UTRAN system for 3GPP accesses.
  • the EUTRAN access network in addition to the Sl-MME interface shown in Figure 1, there is also shown an Sl-U interface to a serving gateway.
  • the serving gateway is interfaced with the MME (SIl interface) , with a serving gateway support node SGSN (S4 interface), with UTRAN (S12 interface), and with a packet data network (PDN) gateway (S5 interface) .
  • Serving Gateway and PDN Gateway may belong to the same network node and in that case, S5 is a node-internal interface.
  • IMT-Advanced may include device-to-device (D2D) communication to enable new types of services, and flexible spectrum use to increase the spectral efficiency in a multi-operator environment.
  • D2D device-to-device
  • D2D communication i.e. a direct communication between at least two devices such as e.g. user equipments or terminals, or servers and terminals of any kind, is being dealt with herein.
  • D2D device-to-device
  • WLAN wireless local area network
  • Hiperlan/2 Hiperlan/2
  • Tetra fundamental architectures, conditions and requirements underlying such systems essentially differ from those underlying wireless/cellular communication systems. Therefore, cognition on device-to-device (D2D) communication in such systems is not transferable to wireless/cellular communication systems.
  • the Local Breakout provides a technique for local connectivity in addition to (or instead of) wide area IP (Internet Protocol) connectivity and setting up of an SAE (System Architecture Evolution) bearer.
  • SAE System Architecture Evolution
  • the eNodeB is further proposed to contain local scope DHCP (Dynamic Host Configuration Protocol) discovery to find a local gateway to which it can attach the user equipment to. IP connectivity between the user equipment and the local gateway offers the opportunity for the user equipment to make local IP calls inside the local subnet via the local gateway.
  • DHCP Dynamic Host Configuration Protocol
  • this known Local Breakout technique does not include feasibility for direct device-to-device communication, because IP connectivity and routing happen by/via the local gateway (also referred to as the access router) .
  • a method comprising creating an address of a destination device for device-to-device communication to be of a local address format, creating a session initiation request for device-to-device communication using the created local address format of the destination device, and sending the created session initiation request on a control plane to a local serving network node.
  • the method comprises sending the created session initiation request using a control plane message to a local network node
  • the session initiation request comprises a session initiation protocol invitation message
  • control plane message comprises a non-access stratum message
  • the method comprises adding a session initiation protocol identifier, - the local address format indicates that the devices for device-to-device communication are located in a common subnet area of a communication network,
  • the local address format is a predetermined format of at least one of a network address identifier, an Internet address, an Intranet address, a phone number, a uniform resource identifier, and a uniform resource locator,
  • the method comprises establishing a local device-to- device bearer to the destination device upon request from the local network nod, - the local network node is at least one of a network access node such as a base station and a mobility management entity, and/or
  • the method is operable at a source device for device- to-device communication.
  • a method comprising receiving a control plane message including a session initiation request for device-to-device communication from a local network node, identifying, in the received control plane message, a session initiation protocol identifier, and processing the session initiation request for initiating device-to-device communication with a source device.
  • the method comprises establishing a local device-to- device bearer to the source device upon request from the local network node,
  • the session initiation request comprises a session initiation invitation message
  • control plane message comprises a non-access stratum message
  • the method is operable at a destination device for device-to-device communication.
  • a method comprising receiving a control plane message including a session initiation request for device-to-device communication, detecting, in the received control plane message, a session initiation protocol identifier, and forwarding the control plane message including the session initiation request for device-to-device communication for another network node.
  • control plane message when the control plane message is received from a device, the control plane message is forwarded to a local network node, and when the control plane message is received from a local network node, the control plane message is forwarded to a device,
  • control plane message comprises a non-access stratum message
  • the method comprises setting up a device-to-device bearer between devices for device-to-device communication upon receipt of a device-to-device bearer set-up request from a local network node
  • the local network node is a mobility management entity, and wherein the device is one of a source device and a destination device for device-to-device communication, and/or
  • the method is operable at a network access node such as a base station.
  • a method comprising receiving a session initiation request on a control plane from a device, detecting, in the received session initiation request, an address of a destination device for device-to-device communication to be of a local address format, resolving the local address format for locating the destination device and searching for the destination device, and delivering a session initiation request for device-to-device communication using the detected local address format of the destination device on a control plane to the destination device.
  • the method comprises forwarding the created session initiation request using a control plane message to a local network node,
  • the session initiation request comprises a session initiation invitation message
  • control plane message comprises a non-access stratum message
  • the method comprises identifying the received session initiation request as a session initiation invitation message by means of a session initiation protocol identifier,
  • the method comprises issuing a device-to-device bearer set-up request to a local network node, - the the local address format is a predetermined format of at least one of a network address identifier, an Internet address, an Intranet address, a phone number, a uniform resource identifier, and a uniform resource locator, - the local network node is a network access node such as a base station, and wherein the device is one of a source device and a destination device for device-to- device communication, and/or
  • the method is operable at a mobility management entity.
  • an apparatus comprising a creator configured to create an address of a destination device for device-to-device communication to be of a local address format, a creator configured to create a session initiation request for device-to-device communication using the created local address format of the destination device, and a transmitter configured to send the created session initiation request on a control plane to a local serving network node.
  • the transmitter is further configured to send the created session initiation request using a control plane message to a local network node
  • the session initiation request comprises a session initiation protocol invitation message
  • the control plane message comprises a non-access stratum message
  • the apparatus comprises an adder configured to add a session initiation protocol identifier, - the local address format indicates that the devices for device-to-device communication are located in a common subnet area of a communication network,
  • the local address format is a predetermined format of at least one of a network address identifier, an Internet address, an Intranet address, a phone number, a uniform resource identifier, and a uniform resource locator,
  • the apparatus comprises an establisher configured to establish a local device-to-device bearer to the destination device upon request from the local network node,
  • the local network node is at least one of a network access node such as a base station and a mobility management entity, and/or
  • the apparatus comprises a source device for device- to-device communication.
  • an apparatus comprising a receiver configured to receive a control plane message including a session initiation request for device-to- device communication from a local network node, an identifier configured to identify, in the received control plane message, a session initiation protocol identifier, and a session processor configured to process the session initiation request for initiating device-to- device communication with a source device.
  • the session processor is further configured to pass the session initiation request to an application layer for handling device-to-device session initiation,
  • the apparatus comprises an establisher configured to establish a local device-to-device bearer to the source device upon request from the local network node,
  • the session initiation request comprises a session initiation invitation message
  • control plane message comprises a non-access stratum message
  • the apparatus comprises a destination device for device-to-device communication.
  • an apparatus comprising a receiver configured to receive a control plane message including a session initiation request for device-to- device communication, a detector configured to detect, in the received control plane message, a session initiation protocol identifier, and a transmitter configured to forward the control plane message including the session initiation request for device-to-device communication for another network node.
  • the transmitter when the control plane message is received from a device, the transmitter is configured to forward the control plane message to a local network node, and when the control plane message is received from a local network node, the transmitter is configured to forward the control plane message to a device,
  • control plane message comprises a non-access stratum message
  • apparatus comprises a processor configured to set up a device-to-device bearer between devices for device- to-device communication upon receipt of a device-to- device bearer set-up request from a local network node
  • the local network node is a mobility management entity, and wherein the device is one of a source device and a destination device for device-to-device communication, and/or
  • the apparatus comprises a network access node such as a base station.
  • an apparatus comprising a receiver configured to receive a session initiation request on a control plane from a device, a detector configured to detect, in the received session initiation request, an address of a destination device for device- to-device communication to be of a local address format, a resolver configured to resolve the local address format for locating the destination device and to search for the destination device, and a transmitter configured to deliver a session initiation request for device-tp-device communication using the detected local address format of the destination device on a control plane to the destination device.
  • the transmitter is further configured to send the created session initiation request using a control plane message to a local network node
  • the session initiation request comprises a session initiation invitation message
  • control plane message comprises a non-access stratum message
  • the apparatus comprises an identifier configured to identify the received session initiation request as a session initiation invitation message by means of a session initiation protocol identifier
  • the apparatus comprises an issuer configured to issue a device-to-device bearer set-up request to a local network node
  • the local address format is a predetermined format of at least one of a network address identifier, an Internet address, an Intranet address, a phone number, a uniform resource identifier, and a uniform resource locator
  • the local network node is a network access node such as a base station
  • the device is one of a source device and a destination device for device-to- device communication, and/or
  • the apparatus comprises a mobility management entity.
  • a computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to the first aspect and/or any development or modification thereto,
  • the device-to-device address may include a phone number, a session initiation protocol (SIP) address, or a uniform resource indicator (URI) such as a uniform resource locator (URL), a uniform resource name (URN) or similar.
  • SIP session initiation protocol
  • URI uniform resource indicator
  • URL uniform resource locator
  • UPN uniform resource name
  • a session initiation process which does not involve a non-local session server network node (e.g. SIP server) on the user plane, but instead includes added functionality to another local network node (e.g. MME) to handle session initiation in a local subnet domain, - the addition of a session initiation (e.g. SIP) handler to a local network node such as an MME so as to enable the local network node such as the MME to handle local D2D session initiation requests,
  • a session initiation e.g. SIP
  • a switch point to a device (e.g. application and/or software and/or firmware) that creates wide area session (initiation) requests (to the network) differently than D2D session (initiation) requests (i.e. the device switches the message either to the user plane or to the control plane)
  • a switch point to a device (e.g. application and/or software and/or firmware) that detects and handles, in addition to wide area session (initiation) requests (from the network), D2D session (initiation) requests (from the network) (i.e. despite of detecting and handling these different requests differently, the device switches the session initiation message equally to the application layer for corresponding handling)
  • a switch point to a device (e.g. application and/or software and/or firmware) that creates wide area session (initiation) requests (to the network) differently than D2D session (initiation) requests (i.e. the device switches the message either to the user plane or to the control plane)
  • a switch point to a device (e.g. application and/or software
  • NAS i.e. non-access stratum
  • the network access node e.g. access router, base station, eNodeB, PDN GW, etc.
  • the network access node e.g. access router, base station, eNodeB, PDN GW, etc.
  • radio resources coordination of D2D resources and e.g. cellular resources
  • device-to-device communication includes a direct communication between two or more devices.
  • FIG 1 shows the architecture of an E-UTRAN system according to Release 8
  • FIG. 2 shows the architecture of the E-UTRAN system for 3GPP accesses
  • Figure 3 shows the different entities involved or impacted by device-to-device communication according to an embodiment of the present invention
  • Figure 4 shows a schematic flow diagram of a method at a source-side device according to an embodiment of the present invention
  • Figure 5 shows a signaling flow chart for session initiation using a global destination address
  • Figure 6 shows a signaling flow chart for device-to- device session initiation using a local destination address according to an embodiment of the present invention
  • Figure 7 shows an illustration of device connectivity on different protocols according to an embodiment of the present invention
  • Figure 8 shows a schematic flow diagram of a method at a device according to an embodiment of the present invention
  • Figure 9 shows a schematic flow diagram of a method at a network access node according to an embodiment of the present invention
  • Figure 10 shows a schematic flow diagram of a method at a mobility management entity according to an embodiment of the present invention
  • Figure 11 shows a schematic flow diagram of a method of device-to-device bearer setup according to an embodiment of the present invention
  • Figure 12 shows a schematic flow diagram of a method at a device according to an embodiment of the present invention
  • Figure 13 shows a schematic flow diagram of a method at a destination-side device according to an embodiment of the present invention.
  • Figure 14 shows a schematic block diagram of different apparatuses and their interworking according to an embodiment of the present invention. Detailed description of embodiments of the present invention
  • the present invention and its embodiments are mainly described in relation to 3GPP technologies being used as non-limiting examples for certain exemplary network configurations.
  • an LTE (E-UTRAN) radio access network and corresponding standards (Release-8, Release-9, and LTE-Advanced) are used as a non-limiting example in this regard.
  • the description of the embodiments given herein specifically refers to terminology which is directly related thereto. Such terminology is only used in the context of the presented non-limiting examples, and does naturally not limit the invention in any way. Rather, any other network configuration or implementation may also be utilized as long as compliant with the features described herein.
  • Exemplary embodiments of the present invention enable the initiation of a D2D session in a 3GPP evolved system architecture (SAE) environment.
  • SAE evolved system architecture
  • Session initiation in the meaning used herein my be understood as an application layer process that may also be called session setup.
  • session initiation or setup may be related to IP connectivity, connection management and bearer management processes on the other respective protocol layers.
  • the exemplary embodiments provide a flexible approach to set up a D2D session within the 3GPP SAE (e.g. LTE) using a local number or local address format.
  • local address format may be based on any conceivable numbering or address scheme. For example, it may be based on a network access identifier (NAI) format or any other Internet address format, such as e.g. SIP URI (Session Initiation Protocol Uniform Resource Identifier) or http URL (Hypertext Transfer Protocol Uniform Resource Locator) or URN (Uniform Resource Name) .
  • NAI network access identifier
  • SIP URI Session Initiation Protocol Uniform Resource Identifier
  • http URL Hypertext Transfer Protocol Uniform Resource Locator
  • URN Uniform Resource Name
  • the presence in a local scope may refer for example to Internet or Intranet or it may relate to a cell or a group of neighboring cells of a cellular communication system or any kind of subnet area of an underlying communication system (e.g. an access network) .
  • the locality of a target or destination device of a D2D communication is determined in relation to a source or originating device of a D2D communication.
  • the modification for indicating locality may for example be a specific suffix and/or prefix and/or extension, and/or a keyword, which indicates a valid D2D format.
  • an Internet address e.g. IP address
  • a phone number with a special suffix or prefix may be used.
  • any specifically designed predetermined format modification of a global address or numbering format may be used as local address format, as along as it is suitable for distinguishing between normal (i.e. nonlocal or global) calls and local calls.
  • D2D_keyword For any of these known formats, embodiments of the present invention propose some extension for D2D communication purposes.
  • This extension may, for illustrative purposes, be of the format NAI.
  • D2D or, in more generic terms, of the format: username ⁇ realm.
  • D2D_keyword For any of these known formats, embodiments of the present invention propose some extension for D2D communication purposes.
  • This extension may, for illustrative purposes, be of the format NAI.
  • D2D_keyword for illustrative purposes, be of the format NAI.
  • D2D or, in more generic terms, of the format: username ⁇ realm.
  • D2D_keyword For any of these known formats, embodiments of the present invention propose some extension for D2D communication purposes.
  • This extension may, for illustrative purposes, be of the format NAI.
  • Keyword proposals as mentioned above could be of the format : username@realm. D2D username@realm. direct username ⁇ realm. local
  • a network access identifier with a specific D2D extension is assumed as a local address format for the following description.
  • This exemplary local address format may e.g. be denoted as "NAI. D2D”, and may e.g. take the form "username@LTED2D. direct”.
  • Device-to-device (D2D) communications may share the same band(s) used by the underlying communication system, in this case the cellular (e.g. LTE) network.
  • the cellular e.g. LTE
  • the D2D communication should be controlled and constrained by the cellular network.
  • exemplary embodiments of the present invention relate to a case of a D2D mode (including session initiation) with network support.
  • the network support may in the case of a cellular network be provided by any network access node such as a base station (BS) or NodeB or an evolved eNodeB.
  • the network access node thus supports messaging of the session initiation, connectivity set-up and resource control (e.g. reuse of licensed radio resources) , but is not involved in data transfer. That is, the supporting base station (BS) or NodeB or an evolved eNodeB is only involved on the control plane, and not on the user plane.
  • Exemplary embodiments of the present invention relate to session initiation which may exemplarily happen by IP protocols like the Session Initiation Protocol (SIP) .
  • the session initiation generally takes place on a local scope, e.g. within a local subnet area of e.g. Internet or Intranet or a cell or group of neighboring cells in a cellular network.
  • a local serving network node such as for example a mobility management entity having knowledge of the location of the devices may serve as a session initiation server, i.e. in the case of SIP as a SIP (application) server, for local sessions, i.e. for sessions for local device-to-device calls.
  • Session Description Protocol (SDP) messages may be delivered in the context of session initiation. Yet, an embodiment is that SDP and further session control messaging as signaling the media types will happen directly over the D2D bearer once established as a consequence of this session initiation process. Thus, more media components or more sessions could be added by directly communicating over the D2D connection.
  • SDP Session Description Protocol
  • FIG 3 shows the different entities involved or impacted by device-to-device (D2D) communication according to an embodiment of the present invention.
  • D2D device-to-device
  • the thus depicted situation exemplarily relates to the case of a cellular network, wherein the illustrated entities belong to a single cell thereof.
  • These entities include the devices (D, such as the UEs shown in Figures 1 and 2) .
  • Devices D D and D D+ i as well as devices D 1 and D 1+i are engaged in a mutual D2D communication session, respectively.
  • a cellular link is active with respect to device D k , and the base station (eNB 12) serves as a network access node to the (non-local) network e.g. Internet.
  • eNB 12 serves as a network access node to the (non-local) network e.g. Internet.
  • the dashed arrows indicate possible control links, i.e. links on the control plane e.g. for Radio Resource Control (RRC) messaging.
  • RRC Radio Resource Control
  • An association status with the eNodeB is checked. If associated with the eNodeB, the eNodeB is contacted for permission to engage in D2D communication. If granted, the device engages in the D2D mode with eNodeB support of this eNodeB.
  • the device engages in the D2D mode with eNodeB support of the thus scanned eNodeB.
  • network (eNodeB) control can be applied.
  • eNodeB network control for D2D communication.
  • Control operations being available at the eNodeB as such may for example include or being based on at least one of the following:
  • control interface for the network access node which is provided by the dashed line links according to Figure 3, at least one of the following control operations may be provided.
  • the eNodeB could reserve some (time, frequency, code sequence, spatial) resources to the D2D devices, which they schedule themselves.
  • the eNodeB could remain in control of all resource or power allocations.
  • the eNodeB could set constraints and operational regime for a D2D link.
  • the eNodeB could make one device lead in the D2D communication and grant resources to that node.
  • the eNodeB could request measurements.
  • One probable measurement could be the D2D link quality. It is to be noted that such measurements depend on the technique selected for the D2D radio interface.
  • the eNodeB could cancel a D2D link.
  • the eNodeB could re-establish the communication via cellular links.
  • the eNodeb could remain passive after just initiating the D2D session.
  • the network access node e.g. the base station or eNodeB
  • the network access node can identify a call as a D2D call by detecting a local address format, e.g. a specific Network Address Identifier (NAI) format for D2D communications (local number, NAI. D2D), of the destination device for communication.
  • NAI Network Address Identifier
  • the source device e.g. UEl
  • the destination device e.g. UE2
  • a session setup request such as e.g. a SIP INVITE message using the local NAI. D2D of UE2.
  • a switch point (in case of SIP protocol session initiation a SIP switch point) for the new NAI.
  • D2D format e.g. in the device.
  • the switch point in the device handles the addresses of local address format differently than the addresses of normal (SIP) addresses.
  • FIG. 4 shows a schematic flow diagram of a method at a source-side device according to an embodiment of the present invention.
  • This flow diagram refers to the source device originating the session initiation process.
  • an exemplary SIP message representing a session initiation (set-up) request message is created, and a corresponding SIP destination address is created depending on user input or selection by service software.
  • the further process is to be distinguished whether or not the thus created destination address contains a D2D extension, i.e. whether or not the destination address is of local scope (S401) . If so (i.e. YES in S401), the local address (e.g. NAI.
  • S401 local scope
  • D2D or, in more generic terms, username@realm.D2D keyword) is used for session initiation taking place over the control plane.
  • the local address is used for creating a corresponding request message (S402)
  • a control plane (e.g. non-access stratum, NAS) request message is sent locally (S403) to a corresponding service access point (e.g. NAS SAP), and the local address is resolved at a local serving network node such as e.g. a mobility management entity MME (S404), which is thus enabled to search for the destination device.
  • the application layer writes the SIP message to the application programming interface (API) for the firmware of the UE, which receives the e.g.
  • API application programming interface
  • the firmware writes to the NAS SAP, from where the NAS protocol software processes the NAS protocol headers, copies the application data inside the NAS container, and the delivery is handled by the cellular protocols to the MME. Details of these control plane procedures are given in connection with Figure 6 below.
  • the non-local global/normal address (e.g. NAI or, in more generic terms, username ⁇ realm) is used for session initiation taking place over the user plane.
  • the global address (e.g. username@realm) is used for creating a corresponding request message (S405)
  • a user plane request message is sent to a local packet data network (PDN) gateway (GW) (S406) and further to a non-local SIP server (S407) .
  • PDN packet data network gateway
  • S407 a non-local SIP server
  • the application layer writes the SIP message to the application programming interface (API) for the firmware of the UE, which receives the e.g.
  • API application programming interface
  • SIP INVITE message in API function call in a proper format having the destination username (i.e. SIP level address), and the function call further includes instructions to place this message to the TCP/IP port.
  • the firmware identifies what is the TCP port number to open and which IP address to use. Then, the TCP/IP socket or such is openend, and SIP INVITE message is transmitted there in a TCP/IP datagram. Details of these user plane procedures are given in connection with Figure 5 below.
  • the device when the device creates local destination address (i.e. a destination address with a D2D extension), it will not use the NAI format and send the request over the user plane (UP), but it will use the NAI. D2D format and send the request e.g. using a Non-Access Stratum (NAS) control plane (CP) message.
  • NAS Non-Access Stratum
  • CP control plane
  • FIG. 5 shows a signaling flow chart for session initiation using a global destination address (URI, URL, URN or such) .
  • This user plane procedure for session initiation for non-local communication comprises, the establishment of a radio resource control (RRC) connection between the source device UEl and eNodeB, the set-up of an SAE bearer between the source device UEl and the PDN gateway, the sending of a SIP INVITE message using the global address on the user plane from the source device UEl via the PDN GW to a SIP application server (SIP AS) , the routing of this SIP INVITE message from the PDN GW to the non-local destination device UE2, and the returning of SIP response messages from the destination device UE2 to the source device UEl over the SIP application server.
  • the PDN GW acts as the IP level gateway and router, and it does not process the SIP application messages.
  • Figure 6 shows a signaling flow chart for device-to- device session initiation using a local destination address (modified URI, URL, URN or such, e.g. the NAI. D2D) according to an embodiment of the present invention.
  • a local destination address modified URI, URL, URN or such, e.g. the NAI. D2D
  • an internal arrangement of the individual devices UEl and UE2 is indicated using an illustration of an application layer "appl”, a non- access stratum layer “NAS” and a radio resource control layer “RRC”
  • an internal arrangement of the eNodeB is indicated using a non-access stratum layer "NAS” and a radio resource control layer "RRC”.
  • the local scope comprises the devices UEl and UE2, the eNodeB, the MME and the PDN gateway, while the SIP application server (SIP AS) represents a non-local network node. It may be seen that the entire procedure runs in the local scope, and the SIP server is not involved.
  • SIP AS SIP application server
  • the actual session initiation procedure takes place as follows.
  • RRC radio resource control
  • a local NAI. D2D address format of the destination device UE2 is created by the source device UEl e.g. by a user selecting the address format or by the application picking up an address format in preferred order. Then, the source device UEl sends a session set-up request e.g. in the form of a SIP [NAI. D2D, invite] message to the MME. This may e.g. be effected by using a NAS c-Plane message (as shown in the box below the respective SIP INVITE message) , which is forwarded via the eNodeB to the MME. In other words, the application of device UEl does not send the request to the u-Plane port (e.g. TCP/IP port or UDP/IP port) , but it sends it to the NAS service access point (NAS SAP) instead.
  • NAS service access point NAS service access point
  • a session initiation protocol e.g. SIP
  • SIP session initiation protocol
  • MME mobility management entity
  • NAS messages as message containers
  • RRC messages between the UE and the eNB
  • Sl Application protocols between the eNB and MME.
  • the transport between eNodeB and MME may for example be an IP tunnel.
  • the MME acts as a session initiation server functionality (e.g. similar than a SIP server) .
  • session initiation messages e.g. SIP messages inside the NAS container containing a SIP protocol identifier
  • the MME is provided with a corresponding session initiation handler, e.g. with a SIP handler.
  • the SIP handler (which may also be referred to as a "light SIP server") receives the SIP [NAI. D2D invite] message, and knows where to find the destination device UE2 under the mobility management of that MME, if it is in the same subnet or if it is associated to one of the eNodeB' s in the neighborhood.
  • the MME knows the (SIP) presence and knows the address information, that is e.g. dynamic Mobile IP addresses, of the devices attached to it.
  • the MME may create its own subnet and give new IP addresses from that local subnet scope for source device UEl and destination device UE2. (These IP addresses would serve D2D IP connectivity only.)
  • the MME then forwards the SIP [NAI. D2D invite] message to the destination device UE2. This may e.g. be effected by using a NAS c-Plane message (as shown in the box below the respective SIP INVITE message), which is forwarded via the eNodeB to the destination device UE2.
  • the destination device UE2 detects, once it receives a NAS message (i.e. a NAS message container containing a SIP message) , from the SIP protocol identifier of that NAS message (i.e. a NAS message container containing a SIP message) , from the SIP protocol identifier of that NAS message (i.e. a NAS message container containing a SIP message) , from the SIP protocol identifier of that
  • the destination device UE2 acts on the SIP INVITE message as if it were received from the SIP server on the u-plane, although it was received in the NAS message on the c-plane. Then, the destination device sends a SIP response message to the MME, and the MME forwards the SIP response to source device UEl.
  • the MME requests the eNodeB to set up a D2D radio bearer by issuing a D2D radio bearer set-up request.
  • the eNodeB sets up the D2D bearer between the source device UEl and the destination device UE2.
  • the eNodeB confirms the successful D2D bearer setup to the MME.
  • the execution of the D2D radio bearer set-up as such is not covered by the present invention. It may be performed in any conceivable manner, e.g. as shown in Figure 11.
  • Figure 11 shows a schematic flow diagram of a method of device-to-device bearer setup according to an embodiment of the present invention.
  • IP connectivity may be provided, and a SIP session for D2D communication between UEl and UE2 can be established. After that, D2D data may be directly exchanged between devices UEl and UE2.
  • any Session Description protocol or session control may happen on the D2D bearer directly.
  • the peer devices may initiate further sessions, terminate sessions or change their parameters and/or media types on that D2D connection directly.
  • the session can be initiated without involving a SIP server.
  • the additional delay from involving a SIP server can be avoided.
  • the eNodeB receives NAS messages and forwards them to the MME, but it does not process application layer messages as SIP.
  • the session protocol identifier in the NAS message is actually for the MME to know that the embedded message is SIP. This is needed because MME will receive NAS messages for various purposes, e.g. security and authentication.
  • the SIP protocol identifier lets MME pass the SIP message extracted from inside the NAS message to the SIP handler. (Other NAS contents, e.g. authentication, will go to the authentication protocol software) .
  • the eNodeB may detect the SIP protocol identifier in the NAS message, so that it knows to pass that part of the NAS message to the MME.
  • all NAS messages will go from the UE to the MME without eNodeB actively processing them.
  • NAS messages from the MME will go to the UE without eNodeB actively processing them. That is, the eNodeB just delivers the NAS messages (e.g. inside an RRC message container) to the UE.
  • the eNodeB itself could process the application layer protocol (SIP) and detect the address format of local scope.
  • SIP application layer protocol
  • Figure 7 shows an illustration of device connectivity on different protocols according to an embodiment of the present invention. Namely, Figure 7 illustrates the connectivity between different protocol layers at the two above-mentioned devices engaged in D2D communication.
  • the session (e.g. SIP) messages are sent from the application layer of the devices.
  • the bearer setup is done at the RRC layer, and the IP connectivity is between the IP layers (i.e. TCP/UDP) at the devices.
  • IP layers i.e. TCP/UDP
  • IP connectivity (previously referred to in the context of the Local Breakout concept) might be preferred even in the D2D communication case (where it is not mandatorily needed) .
  • IP connectivity can virtually be established between the peer devices. This means that the MME delivers local scope IP addresses (i.e. D2D IP addresses) to source device UEl and destination device UE2 for D2D communication, but there will be no routing function needed.
  • IP addresses for D2D communications are not necessarily needed, because after the set-up the devices directly know the needed Logical Channel ID (LCID) and know the allocated resources for (D2D) communication.
  • LCID Logical Channel ID
  • D2D allocated resources for
  • having IP addresses in use makes the protocol stack and connectivity more consistent to the normal (widea area) operation. This consistency is beneficial in certain operations.
  • the virtual IP connectivity can be established by the MME and may be carried inside the control plane (e.g. NAS) messages so that a D2D bearer request message includes IP addresses for source device UEl and destination device UE2 embedded inside the message elements.
  • the eNodeB While setting up the D2D bearer, the eNodeB will also inform the devices about their IP addresses inside the embedded control plane (e.g. NAS) message. That is, the source device UEl will get to know its own IP address and the IP address of its peer entity UE2, whom it invited for a (SIP) session. The destination device UE2 will also get to know its own IP address and the IP address of its peer entity UEl. After the setup, the devices have readily available source IP address and destination IP address, D2D bearer identity (D2D BID) and logical channel ID (LCID) available for D2D communications.
  • D2D BID D2D bearer identity
  • LCID logical channel ID
  • the MME may get the IP addresses for D2D communication between source device UEl and destination device UE2 from an assigned local pool (e.g. discovery from a DHCP), or it may itself assign addresses for them as long as they do not conflict with any other IP address in the same subnet, i.e. local scope. While different IP assignment strategies can be used, it is preferable to have a separate pool of addresses available at the MME so that the MME creates and manages its own subnet. According to certain exemplary embodiments of the present invention, the following messages and their respective contents are provided.
  • a session invitation message e.g. SIP INVITE
  • a new SIP message e.g. named SIP_D2D_invite could be defined.
  • the NAI. D2D format can have for example the following format "username@LTED2D. direct” .
  • a control plane message e.g. a NAS message, that contains the SIP message [D2D, invite] and that is directed to the MME.
  • a protocol identifier e.g. NAS message header
  • the IP address fields could be embedded as NAS message fields and not directly as fields of the RRC message.
  • IP addresses it is needed to have IP addresses to tell eNodeB as to which devices are involved.
  • the UE IDs e.g. S-TMSI (Supporting Temporary Mobile Subscriber identity)
  • the IP address fields could be embedded as NAS message fields.
  • a D2D bearer setup message concerning radio bearer set-up for D2D communication is needed.
  • c-RNTI cell Radio Network Temporary Identifier
  • c-RNTI cell Radio Network Temporary Identifier
  • c-RNTI cell Radio Network Temporary Identifier
  • c-RNTI cell Radio Network Temporary Identifier
  • c-RNTI cell Radio Network Temporary Identifier
  • c-RNTI cell Radio Network Temporary Identifier
  • Bearer ID and logical channel ID for the D2D connection are needed. All of these are given by the eNodeB. It should be noted that multiple D2D bearers may be set up by a single setup message simultaneously, if necessary.
  • a D2D Bearer including at least one of bearer ID, c- RNTI, and logical channel ID.
  • a local address or number list may be maintained at the MME.
  • the local address or number may be a part of subscription information of the devices in the home subscription server (HSS) , from where the MME may fetch it.
  • HSS home subscription server
  • the MME may store the local number or address temporarily, or may even deliver it to the eNodeB for temporal storing.
  • the device connects to another device using the local address format (e.g. the NAI. D2D format), without performing a complete call setup via the external (core) network such as e.g. the Internet.
  • the local address format e.g. the NAI. D2D format
  • the external (core) network such as e.g. the Internet.
  • This option assumes that either the local number or address is used within the network of one operator, or that the local numbers or addresses are stored/registered with the HSS of an operator.
  • the source device may get an indication of denial such as e.g. a "D2D connection not possible" message, and it can then alternatively initiate a connection set-up using the normal SIP session set-up and address format, as illustrated in Figure 5 above.
  • the available local numbers or addresses in the vicinity of a device can be advertised by the eNodeB as an (operator) service, or they can be printed/displayed on a device with D2D connectivity (e.g. media server) . Thereby, the discovery of local numbers or addresses in a local scope such as a cell may be accomplished.
  • the normal/global number or address may be converted to a local number or address.
  • IMS IP Multimedia Subsystem
  • this may be effected e.g. by a call state control function (CSCF) .
  • CSCF call state control function
  • the device obtains the local number or address from the CSCF, and it can use that local number or address for subsequent D2D communication attempts.
  • the user of the device may store the local addresses in the address book as extensions of the global addresses of the respective contacts. (This may simply be a choice of "allow local calls", and the software knows to convert the address respectively.)
  • SIP Session Initiation Protocol
  • SIP messaging may include SDP (Session Description Protocol) fields indicating e.g. media types and media formats of the session, i.e. of the traffic to be exchanged in the session .
  • SDP Session Description Protocol
  • LBO-internal session set-up for D2D communication i.e. D2D mode
  • LTE/SAE using a local address format
  • LBO Local Breakout
  • the MME additionally sets up a local SAE radio bearer between the device and the eNodeB. This set-up may happen at the initial request by the device.
  • the eNodeB is further proposed to contain some networking protocols e.g. for local scope DHCP discovery to find a local gateway to which it can attach the device to.
  • IP connectivity between the device and the local gateway offers the opportunity for the device to make local IP calls inside the local subnet via the local gateway. Further, it is possible for the device to access the global Internet, if the local gateway has such functionality. This however, may make the local gateway a performance bottleneck.
  • the LBO solution does not yet include a D2D communication option, as described hereinbefore. Accordingly, the basic ideas underlying the above- described eNodeB-supported set-up for D2D communication are also applicable to the LBO concept. Namely, the MME may serve the session set-up (because control plane signaling is used) , and may avoid involvement of wide are core network, which makes response times for local calls (including D2D calls) shorter. Thus, the D2D set-up according to embodiments of the present invention may also be implemented within an LBO framework.
  • the MME in LBO sets up SAE bearers, but it can not set up the D2D bearer.
  • the MME sends a request to the eNodeB to set up a D2D bearer between the devices.
  • the eNodeB sets up a D2D radio bearer, which can also be considered as a special SAE level D2D bearer in the SAE bearer model.
  • the bearers may be named D2D SAE bearer and D2D radio bearer, but may shortly be called D2D bearers.
  • the service data units (SDUs) delivered on the D2D bearer are mapped (one-to-one) to a logical channel with an LCID.
  • the LCID is allocated by the eNodeB and is informed to both devices UEl and UE2.
  • Figure 8 shows a schematic flow diagram of a method at a device according to an embodiment of the present invention .
  • the exemplary method according to Figure 8 may for example be executed at a user equipment UE acting as a source device of D2D communication.
  • a destination address for session initiation is created in that it is decided by the user or by the application whether an address of a destination device for device-to-device communication is of a local address format (e.g. NAI. D2D) . If so (i.e. YES in S801b) , a session initiation request (e.g. SIP INVITE) for device- to-device communication using the created local address format of the destination device is created (S802), and the thus created session initiation request (e.g. SIP INVITE) is written to a corresponding service access point of the control plane (e.g.
  • a session initiation request e.g. SIP INVITE
  • SIP INVITE session initiation request for device- to-device communication using the created local address format of the destination device
  • the sending of S804 may comprise a sending of a control plane message such as a NAS message, which is sent to the MME via an eNodeB.
  • a session-initiation-protocol identifier e.g. a SIP identifier
  • S803 a session-initiation-protocol identifier
  • a local device-to-device bearer to the destination device may be established upon a corresponding request from the eNodeB.
  • a device-to-device IP connectivity (as a non-limiting example for any kind of traffic transmission connectivity) in S806, and a device-to-device session may finally be established in S807.
  • IP connectivity is established between the user equipment and the (non-local) network.
  • the previous establishment of IP connectivity is necessary for non-local session initiation. This is because otherwise the user equipment is not able to send any message, to connect to e.g. web services, or in this case to establish a session with another user equipment in non-local scope.
  • a session initiation request e.g.
  • SIP INVITE using the global/normal address format of the destination device is created, is written to the TCP/IP or UDP/IP port of the user plane, and is sent to the non-local SIP server (S810) .
  • S810 non-local SIP server
  • S811 a (non-local) session may finally be established e.g. between the present user equipment and another user equipment or between the present user equipment and an Internet Service Provider (ISP) .
  • ISP Internet Service Provider
  • Figure 9 shows a schematic flow diagram of a method at a network access node according to an embodiment of the present invention.
  • the exemplary method according to Figure 9 may for example be executed at a base station (BS) or NodeB or eNodeB acting as a network access node in the local scope of D2D communication.
  • BS base station
  • NodeB NodeB
  • eNodeB acting as a network access node in the local scope of D2D communication.
  • a control plane message (e.g. NAS message) including a session set-up request (e.g. SIP INVITE) for device-to-device communication is received from the source device or an MME (depending on the phase of session initiation, cf. Figure 6) .
  • the control plane message (e.g. NAS message) is detected, i.e. the message type of the session initiation protocol (SIP) is detected.
  • the control plane message (e.g. NAS message) including the session initiation request (e.g. SIP INVITE) for device-to-device communication is forwarded (i.e. delivered) to another local serving network node such as a MME (if received from the source device) or to the destination device (if received from the MME) .
  • a session initiation protocol identifier (e.g. a SIP identifier) may be identified in thus received the NAS message embedding the session initiation request (e.g. SIP INVITE), if added thereto in an adding operation at the device side.
  • the session initiation request (e.g. SIP INVITE) is transparently passed from the source device through the network access node to the competent local serving network node (e.g. MME) .
  • the competent local serving network node e.g. MME
  • the direction of passing-through may also be vice versa, i.e. from the competent local serving network node (e.g. MME) through the network access node to the destination device.
  • the competent local serving network node e.g. MME
  • a device-to-device bearer between the source device and the destination device for device- to-device communication may be set up upon receipt (in S904) of a device-to-device bearer set-up request from the competent local serving network node (e.g. MME) .
  • the competent local serving network node e.g. MME
  • IP addresses for D2D communication i.e. the own IP address and the peer IP address
  • the D2D bearer may be acknowledged to the MME
  • the IP addresses may be distributed to the source device and the destination device. That is, IP connectivity may be provided.
  • Figure 10 shows a schematic flow diagram of a method at a mobility management entity according to an embodiment of the present invention.
  • the exemplary method according to Figure 10 may for example be executed at a local serving network node acting as a mobility management entity (being responsible for devices of a D2D communication.
  • a session initiation request (e.g. SIP INVITE) for device-to-device communication is received from a source device.
  • the receiving may comprise a receiving of a control plane message (e.g. NAS message) including a session set-up request (e.g. SIP INVITE) from an eNodeB.
  • a control plane message e.g. NAS message
  • a session set-up request e.g. SIP INVITE
  • a session initiation protocol identifier (e.g. a SIP identifier) may be identified in thus received the NAS message embedding the session initiation request (e.g. SIP INVITE), if added thereto in an adding operation at the device side.
  • the MME may identify the message as a SIP message to be passed to a SIP handler, and the MME may thus server as a (light) SIP server.
  • an address of a destination device for device- to-device communication is detected (by a SIP handler at the MME) in the thus received session set-up request (e.g. SIP INVITE) to be of a local address format (e.g. NAI. D2D) .
  • the local address format is resolved for locating the destination device (with a possible help from the HSS) , and the destination device may be searched in the respective subnet (i.e. local scope) .
  • the MME acting as (light) SIP server may search the destination device, i.e. its TMSI and/global IP address, so that it can contact the destination device for session initiation, e.g. by a control plane (NAS) message.
  • NAS control plane
  • INVITE for device-to-device communication is further delivered (S1005) on the control plane to the destination device of D2D communication.
  • the delivery of S1005 may comprise a sending of a control plane message such as a NAS message, which is sent to the destination device vie the eNodeB.
  • a device-to-device bearer set-up request may be issued to a local serving network node such as an eNodeB acting as network access node.
  • the MME can act as a SIP server, search for the peer (i.e. the destination device) in the local subnet scope, create IP addresses for the D2D peer devices, provide IP connectivity between the peers, and request the eNodeB to set up a D2D bearer.
  • the MME will forward the SIP message using identifiers of the destination device UE2 (either its TMSI or IP address or both) via the eNodeB to the destination device UE2.
  • the eNodeB will set up the bearers, also D2D bearers, and will deliver the IP addresses to UEl and UE2, and the SIP message will reach the destination device UE2, in the embedded NAS message.
  • Figure 12 shows a schematic flow diagram of a method at a device according to an embodiment of the present invention .
  • the exemplary method according to Figure 12 may for example be executed at a user equipment UE acting as a destination device of D2D communication.
  • a session initiation request (e.g. SIP INVITE) for device-to-device communication is received from a MME on the control plane.
  • the receiving may comprise a receiving of a control plane message (e.g. NAS message) including a session set-up request (e.g. SIP INVITE) from an eNodeB.
  • a control plane message e.g. NAS message
  • a session set-up request e.g. SIP INVITE
  • a session initiation protocol identifier (e.g. a SIP identifier) may be identified in thus received the NAS message embedding the session initiation request (e.g. SIP INVITE), if added thereto.
  • the UE2 may identify the message as a SIP message to be passed to a SIP handler at the application layer.
  • the SIP INVITE message is processed as it were received on the user plane. Namely, the SIP INVITE message will be processed to establish the SIP session between UEl and UE2. Further communications about the sessions between UEl and UE2 may happen via the D2D interface.
  • a local device-to-device bearer to the destination device may be established upon a corresponding request from the eNodeB.
  • a device-to-device IP connectivity (as a non-limiting example for any kind of traffic transmission connectivity) in S1205, and a device-to-device session may finally be established in S1206.
  • Figure 12 only illustrates a method in the case of a local D2D session initiation on the control plane according to embodiments of the present invention, i.e. user equipment UE2 acting as a destination device of D2D communication
  • the user equipment UE2 may likewise act as destination device of a normal (i.e. global or non-local) communication, i.e. in the case of a non-local session initiation on the user plane.
  • the different operations in these two cases are illustrated in Figure 13.
  • Figure 13 shows a schematic flow diagram of a method at a destination-side device according to an embodiment of the present invention.
  • the device e.g. application and/or firmware and/or software
  • the device reads the non-access stratum service access point NAS SAP, to where the NAS protocol software has processed message contents after handling the NAS protocol headers, and it copies (i.e. passes) the application data via the application programming interface (API) to the application software capable of handling session initiation e.g. by way of the Session Initiation Protocol, for further processing (e.g. the SIP INVITE message) .
  • the device e.g.
  • the application and/or firmware and/or software of the destination device UE2 receives a TCP connection request, and the TCP/IP port is open for the application software.
  • the application layer session initiation protocol receives e.g. SIP INVITE message in an API function call from the TCP/IP port.
  • Figure 14 shows a schematic block diagram of different apparatuses and their interworking according to an embodiment of the present invention.
  • the thus depicted apparatuses may for example be implemented in or by a (source and/or destination) device or user equipment, a base station or an evolved radio access node (e.g. eNodeB) in an evolved broadband radio access network (e.g. LTE, E-UTRAN), and a mobility management entity MME, respectively.
  • a device or user equipment, such a base station or an evolved radio access node (e.g. eNodeB), and such a mobility management entity MME represent particular machines on which a corresponding software implementation of the respective embodiments may be stored and/or executed.
  • Figure 14 contains four distinct apparatuses (i.e.
  • any one of these apparatuses represents an autonomous entity according to respective embodiments of the present invention, while their interworking entirety or any conceivable combination thereof represents a system according to an embodiment of the present invention.
  • the solid line blocks are basically configured to perform the respective operations.
  • the entirety of blocks is basically configured to perform the methods and operations as described above, respectively.
  • the individual blocks are meant to illustrate respective functional blocks implementing a respective function, process or procedure, respectively.
  • Such functional blocks are implementation-independent, i.e. may be implemented by means of any kind of hardware or software, respectively.
  • the lines/arrows interconnecting individual blocks are meant to illustrate an operational coupling there-between, which on the one hand is implementation- independent (e.g. wired or wireless) and on the other hand may also comprise an arbitrary number of intermediary functional entities not shown.
  • the thus depicted source device or user equipment comprises a (software) switch (or in the exemplary SIP case a SIP switch) , a creator and an adder constituting a format handler or in the exemplary SIP case a SIP format handler) , and a transmitter and/or receiver constituting a transceiver TRX.
  • the (address format) creator represents means creating an address of a destination device for device-to-device communication to be of a local address format, and for creating a session initiation request (e.g.
  • the transceiver represents means for sending the created session initiation request on a control plane to a local serving network node such as e.g. the depicted MME.
  • the transceiver may also represent means for sending the created session initiation request using a control plane message (e.g. NAS message) to a local serving network node such as e.g. the depicted eNodeB.
  • a control plane message e.g. NAS message
  • the adder represents means for adding a session initiation (e.g. SIP) protocol identifier e.g. to a thus created NAS message.
  • a D2D bearer establisher (not shown) represents means for establishing a local device-to- device bearer to the destination device upon request e.g. from the eNodeB.
  • the various embodiments of the device or user equipment may include, but are not limited to, cellular mobile phones, multimedia devices, communicators, mini- laptops, personal digital assistants (PDAs) having wireless communication capabilities, portable computers having wireless communication capabilities, image capture devices such as digital cameras having wireless communication capabilities, gaming devices having wireless communication capabilities, music storage and playback appliances having wireless communication capabilities, Internet appliances permitting wireless Internet access and browsing, as well as portable units or terminals that incorporate combinations of such functions .
  • PDAs personal digital assistants
  • portable computers having wireless communication capabilities
  • image capture devices such as digital cameras having wireless communication capabilities
  • gaming devices having wireless communication capabilities
  • music storage and playback appliances having wireless communication capabilities
  • Internet appliances permitting wireless Internet access and browsing, as well as portable units or terminals that incorporate combinations of such functions .
  • the thus depicted network access node i.e. eNodeB or BS
  • the network access node comprises a detector, a transmitter and/or receiver constituting a transceiver TRX (which is depicted as being separated for two transmission directions, which is however only for illustrative purposes) , an identifier, and an D2D bearer processor.
  • the detector represents means for detecting, in a received control plane message (e.g. NAS message) , a SIP protocol identifier, and the transceivers represent means for receiving and/or sending a control plane message including a session initiation request for device-to-device communication.
  • the transceiver on the left-hand side may represent means for receiving a control plane message including a session initiation request for device-to-device communication (from the source device)
  • the transceiver on the right-hand side may represent means for forwarding the control plane message including the session initiation request for device-to-device communication (to the MME) .
  • the transceiver on the right-hand side may represent means for receiving a control plane message including a session initiation request for device-to-device communication (from the MME), and the transceiver on the right-hand side may represent means for forwarding the control plane message including the session initiation request for device-to-device communication (to the destination device) .
  • the identifier represents means for identifying a session initiation protocol identifier in the control plane message.
  • the eNodeB or BS as such may represent means for transparently passing though a session initiation request (e.g. SIP INVITE) between source/destination device and the MME.
  • the D2D bearer processor may represent means for setting up a device-to-device bearer between source and destination devices for device-to-device communication upon receipt of a device-to-device bearer set-up request e.g. from the MME.
  • the thus depicted local serving network node e.g. the mobility management entity MME, comprises a detector, a resolver and a deliverer and an identifier constituting a handler (or in the exemplary SIP case a SIP handler) , a transmitter and/or receiver constituting a transceiver TRX, and also an D2D bearer issuer.
  • the mobility management entity MME comprises a detector, a resolver and a deliverer and an identifier constituting a handler (or in the exemplary SIP case a SIP handler) , a transmitter and/or receiver constituting a transceiver TRX, and also an D2D bearer issuer.
  • the transceiver represents means for receiving a session initiation request (e.g. SIP INVITE) on a control plane from the device
  • the detector represents means for detecting, in the received session initiation request, an address of a destination device for device-to-device communication to be of a local address format
  • the resolver represents means for resolving the local address format for locating the destination device and for searching for the destination device
  • the deliverer represents means for delivering a session initiation request (e.g. SIP INVITE) for device- to-device communication further using the detected local address format of the destination device
  • the transceiver also represents means for sending it to the destination device.
  • the transceiver may also represent means for receiving the session initiation request using a control plane message (e.g. NAS message) from the eNodeB, and/or means for sending the created session initiation request using a control plane message (e.g. NAS message) to a local network node such as e.g. the depicted eNodeB.
  • a control plane message e.g. NAS message
  • NAS message e.g. NAS message
  • the identifier represents means for identifying the received session initiation request as a session initiation protocol invitation message by means of a session initiation protocol identifier in the received NAS message.
  • the D2D bearer issuer represents means for issuing a device-to-device bearer set-up request to a local serving network node such as e.g. the depicted eNodeB.
  • the thus depicted destination device or user equipment comprises an identifier, a session initiation (e.g. SIP) handler, a transmitter and/or receiver (TRX), and an D2D bearer establisher.
  • a session initiation (e.g. SIP) handler e.g. SIP
  • TRX transmitter and/or receiver
  • D2D bearer establisher e.g. SIP
  • the transceiver represents means for receiving a control plane message (e.g. NAS message) including a session initiation request (e.g. SIP INVITE) for device-to-device communication from a local network node.
  • a control plane message e.g. NAS message
  • a session initiation request e.g. SIP INVITE
  • the identifier represents means for identifying, in the received control plane message, a session initiation protocol (SIP) identifier
  • the SIP handler represents a session processor or, stated in other words, means for processing the session initiation request for initiating device-to- device communication with a source device, which may include passing the session initiation request to an application (e.g. application layer) for handling device- to-device session initiation.
  • an application e.g. application layer
  • the D2D bearer establisher represents means for establishing a local device-to-device bearer to the source device upon request from the local network node (similar to that of the source device, although not shown there) .
  • a device-to-device communication may equally include three or more devices (i.e. multi-party sessions) .
  • one or more of the involved devices may start the multi-party session initiation, while the one or more remaining devices on local scope act as destination devices, respectively.
  • respective functional blocks or elements according to above-described aspects can be implemented by any known means, either in hardware and/or software, respectively, if it is only adapted to perform the described functions of the respective parts.
  • the mentioned method steps can be realized in individual functional blocks or by individual devices, or one or more of the method steps can be realized in a single functional block or by a single device.
  • method steps and functions likely to be implemented as software code portions and being run using a processor at one of the entities are software code independent and can be specified using any known or future developed programming language such as e.g. Java, C++, C, and Assembler.
  • the operation system may include linux, unix, Symbian, Windows, Java J2ME etc.
  • Method steps and/or devices or means likely to be implemented as hardware components at one of the entities are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS, CMOS, BiCMOS, ECL, TTL, etc, using for example ASIC components or DSP components, as an example.
  • any method step is suitable to be implemented as software or by hardware without changing the idea of the present invention.
  • Devices and means can be implemented as individual devices, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device is preserved. Such and similar principles are to be considered as known to those skilled in the art.
  • Software in the sense of the present description comprises software code as such comprising code means for performing the respective functions, as well as software (or a computer program or a computer program product) embodied on a tangible medium such as a computer-readable storage medium having stored thereon a respective data structure or code portions or embodied in a signal or in a chip, potentially during processing thereof.
  • an access technology may be any technology by means of which a user equipment can access an access network (e.g. via a base station, access point or generally an access node) .
  • Any present or future technology such as WLAN (Wireless Local Access Network) /WiFi, WiMAX (Worldwide Interoperability for Microwave Access) , BlueTooth, Infrared, Ultra Wideband (UWB) and the like may be used; although the above technologies are mostly wireless access technologies, e.g. in different radio spectra, access technology in the sense of the present invention may also imply wirebound technologies, e.g.
  • IP based access technologies like cable networks or fixed lines but also circuits switched access technologies; access technologies may be distinguishable in at least two categories or access domains such as packet switched and circuit switched, but the existence of more than two access domains does not impede the invention being applied thereto, - an access network may be any device, apparatus, unit or means by which a station, entity or other user equipment may connect to and/or utilize services offered by the access network; such services include, among others, data and/or (audio-) visual communication, data download etc .
  • a user equipment may be any device, apparatus, unit or means by which a system user may experience services from an access network such as a mobile phone, personal digital assistant PDA, multimedia device, communicator, laptop or computer;
  • - method steps likely to be implemented as software code portions and being run using a processor at a network element or terminal are software code independent and can be specified using any known or future developed programming language as long as the functionality defined by the method steps is preserved;
  • any method step is suitable to be implemented as software or by hardware without changing the idea of the invention in terms of the functionality implemented;
  • any method steps and/or devices, apparatuses, units or means likely to be implemented as hardware components at a terminal or network element, or any module (s) thereof are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), TTL (Transistor-Transistor Logic), etc., using for example ASIC (Application Specific IC (Integrated Circuit) ) components, FPGA (Field-programmable Gate Arrays) components, CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components; in addition, any method steps and/or devices, units or means likely to be implemented as software components may for example be based on any security architecture capable e.g. of authentication, authorization, keying and/or traffic protection;
  • any security architecture capable e.g. of authentication
  • devices, apparatuses, units or means can be implemented as individual devices, apparatuses, units or means, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device, apparatus, unit or means is preserved,
  • an apparatus may be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of an apparatus or module, instead of being hardware implemented, be implemented as software in a (software) module such as a computer program or a computer program product comprising executable software code portions for execution/being run on a processor;
  • a device may be regarded as an apparatus or as an assembly of more than one apparatus, whether functionally in cooperation with each other or functionally independently of each other but in a same device housing, for example.
  • the present invention also covers any conceivable combination of method steps and operations described above, and any conceivable combination of nodes, apparatuses, modules or elements described above, as long as the above-described concepts of methodology and structural arrangement are applicable.
  • session initiation for device-to-device communication using a local address format which exemplarily comprises detecting an address of a destination device for device-to-device communication to be of a local address format, creating a session initiation request for device-to-device communication using the detected local address format of the destination device, and sending the created session initiation request on a control plane to a local serving network node.
  • features thereof may comprise at least one of:
  • the eNodeB optional detection of NAS message with a new session protocol identifier and delivery of NAS message from the source UE to the MME encapsulated in the Sl application protocol or from the MME to the destination UE encapsulated in the RRC message.
  • the eNodeB could detect a D2D call directly by detecting a new local NAI format in the session initiation protocol.
  • the application software which determines, when and to which calls to use the D2D format and how to create the D2D format, a switch point (e.g. implemented in software) to treat regular connections differently from D2D connections, and/or sending of NAI.
  • D2D format messages via NAS messages in the control plane .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

There is provided session initiation for device-to-device communication using a local address format, which exemplarily comprises creating an address of a destination device for device-to-device communication to be of a local address format, creating a session initiation request for device-to-device communication using the detected local address format of the destination device, and sending the created session initiation request on a control plane to a local network node.

Description

Title of the invention
Session initiation for device-to-device communication
Field of the invention
The present invention generally relates to session initiation for device-to-device communication. In particular, the present invention relates to session initiation for device-to-device communication in a broadband radio access network environment.
Background of the invention
In the development of radio communication systems, such as mobile communication systems (like for example GSM (Global System for Mobile Communication) , GPRS (General Packet Radio Service) , UMTS (Universal Mobile Telecommunication System) or the like), efforts are made for an evolution of the radio access part thereof. In this regard, the evolution of radio access networks (like for example the GSM EDGE radio access network (GERAN) and the Universal Terrestrial Radio Access Network (UTRAN) or the like) is currently addressed in research and development as well as in standardization. Accordingly, such improved radio access networks are sometimes denoted as evolved radio access networks (like for example the Evolved Universal Terrestrial Radio Access Network (E- UTRAN) ) or as being part of a long-term evolution (LTE) . Although such denominations primarily stem from 3GPP (Third Generation Partnership Project) terminology, the usage thereof hereinafter is not intended to limit the respective description to 3GPP technology, but is rather intended to generally refer to any kind of radio access evolution irrespective of the specific underlying system architecture .
In the following, for the sake of intelligibility, LTE (Long-Term Evolution according to 3GPP terminology) is taken as a non-limiting example for a broadband radio access network being applicable in the context of the present invention and its embodiments. However, it is to be noted that any kind of radio access network may likewise be applicable, as long as it exhibits comparable features and characteristics as described hereinafter.
Figure 1 shows the architecture of an E-UTRAN system according to Release 8. The E-UTRAN system includes eNBs (EUTRAN Node B' s or evolved Node B's), providing the
E-UTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC) protocol terminations towards the user equipments (UEs) . The eNBs may be interconnected with each other by means of an X2 interface (X2 Application Protocol) . The eNBs are also connected by means of an Sl interface (Sl Application Protocol) to an evolved packet core network, more specifically to a mobility management entity (MME) by means of an Sl-MME interface, as well as to a serving gateway (S-GW) by means of an Sl-U interface. The Sl interface supports a many-to-many relation between MMEs or S-HGWs and eNBs.
Figure 2 shows the architecture of the E-UTRAN system for 3GPP accesses. With respect to the EUTRAN access network, in addition to the Sl-MME interface shown in Figure 1, there is also shown an Sl-U interface to a serving gateway. The serving gateway is interfaced with the MME (SIl interface) , with a serving gateway support node SGSN (S4 interface), with UTRAN (S12 interface), and with a packet data network (PDN) gateway (S5 interface) . Serving Gateway and PDN Gateway may belong to the same network node and in that case, S5 is a node-internal interface.
Currently, enhancements to 3GPP LTE (beyond current LTE- Release 8) are investigated to satisfy the future user needs even higher than LTE. This comprises radio technologies that meet the requirements currently defined for radio technologies, e.g. beyond IMT-2000. 3GPP is currently defining a study item to prepare LTE-Advanced that meets such IMT-Advanced requirements. Competing technologies such as WiMAX (Worldwide Interoperability for Microwave Access) are also expected to define further advanced versions of current standards to become IMT- Advanced technologies. For WiMAX, standardization of IMT- Advanced technology is taking place in the IEEE 802.16m task group.
Aspects of IMT-Advanced may include device-to-device (D2D) communication to enable new types of services, and flexible spectrum use to increase the spectral efficiency in a multi-operator environment.
From these aspects, device-to-device (D2D) communication, i.e. a direct communication between at least two devices such as e.g. user equipments or terminals, or servers and terminals of any kind, is being dealt with herein.
The concept of device-to-device (D2D) communication is basically known from other technologies, for example in wireless local area network (WLAN), Hiperlan/2, and Tetra. Yet, fundamental architectures, conditions and requirements underlying such systems essentially differ from those underlying wireless/cellular communication systems. Therefore, cognition on device-to-device (D2D) communication in such systems is not transferable to wireless/cellular communication systems.
In previous wireless/cellular communication systems (e.g. GSM, GPRS, UMTS), no device-to-device communication has existed. Rather, in such previous systems, all communication between any two devices passes the cellular core network. Thus, no questions or problems concerning device-to-device (D2D) communication did exist there.
In present wireless/cellular communication systems, an additional technique known as the Local Breakout exists. The Local Breakout provides a technique for local connectivity in addition to (or instead of) wide area IP (Internet Protocol) connectivity and setting up of an SAE (System Architecture Evolution) bearer. In the Local Breakout, the eNodeB is further proposed to contain local scope DHCP (Dynamic Host Configuration Protocol) discovery to find a local gateway to which it can attach the user equipment to. IP connectivity between the user equipment and the local gateway offers the opportunity for the user equipment to make local IP calls inside the local subnet via the local gateway.
However, this known Local Breakout technique does not include feasibility for direct device-to-device communication, because IP connectivity and routing happen by/via the local gateway (also referred to as the access router) .
Accordingly, there does not exist any feasible solution to the above drawbacks and requirements in terms of any device-to-device communication.
Summary of embodiments of the invention The present invention and its embodiments are made to address one or more of the above-described drawbacks and requirements. Thus, the present invention and its embodiments are intended to provide solutions to fulfill requirements in session initiation (session set-up) for device-to-device (D2D) communication.
According to exemplary aspects of the present invention, there are disclosed:
- a method as set out in any one of claims 1 to 10,
- a method as set out in any one of claims 11 to 16,
- a method as set out in any one of claims 17 to 22,
- a method as set out in any one of claims 23 to 31, - an apparatus as set out in any one of claims 32 to 41,
- an apparatus as set out in any one of claims 42 to 47,
- an apparatus as set out in any one of claims 48 to 53,
- an apparatus as set out in any one of claims 54 to 62,
- a computer program product as set out in claim 63, - a computer program product as set out in claim 64,
- a computer program product as set out in claim 65, and
- a computer program product as set out in claim 66.
According to an exemplary first aspect of the present invention, there is provided a method comprising creating an address of a destination device for device-to-device communication to be of a local address format, creating a session initiation request for device-to-device communication using the created local address format of the destination device, and sending the created session initiation request on a control plane to a local serving network node.
According to further developments or modifications thereof, one or more of the following applies: - the method comprises sending the created session initiation request using a control plane message to a local network node,
- the session initiation request comprises a session initiation protocol invitation message,
- the control plane message comprises a non-access stratum message,
- the method comprises adding a session initiation protocol identifier, - the local address format indicates that the devices for device-to-device communication are located in a common subnet area of a communication network,
- the local address format is a predetermined format of at least one of a network address identifier, an Internet address, an Intranet address, a phone number, a uniform resource identifier, and a uniform resource locator,
- the method comprises establishing a local device-to- device bearer to the destination device upon request from the local network nod, - the local network node is at least one of a network access node such as a base station and a mobility management entity, and/or
- the method is operable at a source device for device- to-device communication.
According to an exemplary second aspect of the present invention, there is provided a method comprising receiving a control plane message including a session initiation request for device-to-device communication from a local network node, identifying, in the received control plane message, a session initiation protocol identifier, and processing the session initiation request for initiating device-to-device communication with a source device. According to further developments or modifications thereof, one or more of the following applies:
- the comprises passing the session initiation request to an application layer for handling device-to-device session initiation,
- the method comprises establishing a local device-to- device bearer to the source device upon request from the local network node,
- the session initiation request comprises a session initiation invitation message,
- the control plane message comprises a non-access stratum message, and/or
- the method is operable at a destination device for device-to-device communication.
According to an exemplary third aspect of the present invention, there is provided a method comprising receiving a control plane message including a session initiation request for device-to-device communication, detecting, in the received control plane message, a session initiation protocol identifier, and forwarding the control plane message including the session initiation request for device-to-device communication for another network node.
According to further developments or modifications thereof, one or more of the following applies:
- when the control plane message is received from a device, the control plane message is forwarded to a local network node, and when the control plane message is received from a local network node, the control plane message is forwarded to a device,
- the control plane message comprises a non-access stratum message, - the method comprises setting up a device-to-device bearer between devices for device-to-device communication upon receipt of a device-to-device bearer set-up request from a local network node,
- the local network node is a mobility management entity, and wherein the device is one of a source device and a destination device for device-to-device communication, and/or
- the method is operable at a network access node such as a base station.
According to an exemplary fourth aspect of the present invention, there is provided a method comprising receiving a session initiation request on a control plane from a device, detecting, in the received session initiation request, an address of a destination device for device-to-device communication to be of a local address format, resolving the local address format for locating the destination device and searching for the destination device, and delivering a session initiation request for device-to-device communication using the detected local address format of the destination device on a control plane to the destination device.
According to further developments or modifications thereof, one or more of the following applies:
- the method comprises forwarding the created session initiation request using a control plane message to a local network node,
- the session initiation request comprises a session initiation invitation message,
- the control plane message comprises a non-access stratum message,
- the method comprises identifying the received session initiation request as a session initiation invitation message by means of a session initiation protocol identifier,
- the method comprises issuing a device-to-device bearer set-up request to a local network node, - the the local address format is a predetermined format of at least one of a network address identifier, an Internet address, an Intranet address, a phone number, a uniform resource identifier, and a uniform resource locator, - the local network node is a network access node such as a base station, and wherein the device is one of a source device and a destination device for device-to- device communication, and/or
- the method is operable at a mobility management entity.
According to an exemplary fifth aspect of the present invention, there is provided an apparatus comprising a creator configured to create an address of a destination device for device-to-device communication to be of a local address format, a creator configured to create a session initiation request for device-to-device communication using the created local address format of the destination device, and a transmitter configured to send the created session initiation request on a control plane to a local serving network node.
According to further developments or modifications thereof, one or more of the following applies: - the transmitter is further configured to send the created session initiation request using a control plane message to a local network node,
- the session initiation request comprises a session initiation protocol invitation message, - the control plane message comprises a non-access stratum message,
- the apparatus comprises an adder configured to add a session initiation protocol identifier, - the local address format indicates that the devices for device-to-device communication are located in a common subnet area of a communication network,
- the local address format is a predetermined format of at least one of a network address identifier, an Internet address, an Intranet address, a phone number, a uniform resource identifier, and a uniform resource locator,
- the apparatus comprises an establisher configured to establish a local device-to-device bearer to the destination device upon request from the local network node,
- the local network node is at least one of a network access node such as a base station and a mobility management entity, and/or
- the apparatus comprises a source device for device- to-device communication.
According to an exemplary sixth aspect of the present invention, there is provided an apparatus comprising a receiver configured to receive a control plane message including a session initiation request for device-to- device communication from a local network node, an identifier configured to identify, in the received control plane message, a session initiation protocol identifier, and a session processor configured to process the session initiation request for initiating device-to- device communication with a source device.
According to further developments or modifications thereof, one or more of the following applies: - the session processor is further configured to pass the session initiation request to an application layer for handling device-to-device session initiation,
- the apparatus comprises an establisher configured to establish a local device-to-device bearer to the source device upon request from the local network node,
- the session initiation request comprises a session initiation invitation message,
- the control plane message comprises a non-access stratum message, and/or
- the apparatus comprises a destination device for device-to-device communication.
According to an exemplary seventh aspect of the present invention, there is provided an apparatus comprising a receiver configured to receive a control plane message including a session initiation request for device-to- device communication, a detector configured to detect, in the received control plane message, a session initiation protocol identifier, and a transmitter configured to forward the control plane message including the session initiation request for device-to-device communication for another network node.
According to further developments or modifications thereof, one or more of the following applies:
- when the control plane message is received from a device, the transmitter is configured to forward the control plane message to a local network node, and when the control plane message is received from a local network node, the transmitter is configured to forward the control plane message to a device,
- the control plane message comprises a non-access stratum message, - the apparatus comprises a processor configured to set up a device-to-device bearer between devices for device- to-device communication upon receipt of a device-to- device bearer set-up request from a local network node,
- the local network node is a mobility management entity, and wherein the device is one of a source device and a destination device for device-to-device communication, and/or
- the apparatus comprises a network access node such as a base station.
According to an exemplary eighth aspect of the present invention, there is provided an apparatus comprising a receiver configured to receive a session initiation request on a control plane from a device, a detector configured to detect, in the received session initiation request, an address of a destination device for device- to-device communication to be of a local address format, a resolver configured to resolve the local address format for locating the destination device and to search for the destination device, and a transmitter configured to deliver a session initiation request for device-tp-device communication using the detected local address format of the destination device on a control plane to the destination device.
According to further developments or modifications thereof, one or more of the following applies:
- the transmitter is further configured to send the created session initiation request using a control plane message to a local network node,
- the session initiation request comprises a session initiation invitation message,
- the control plane message comprises a non-access stratum message, - the apparatus comprises an identifier configured to identify the received session initiation request as a session initiation invitation message by means of a session initiation protocol identifier, - the apparatus comprises an issuer configured to issue a device-to-device bearer set-up request to a local network node,
- the local address format is a predetermined format of at least one of a network address identifier, an Internet address, an Intranet address, a phone number, a uniform resource identifier, and a uniform resource locator, the local network node is a network access node such as a base station, and wherein the device is one of a source device and a destination device for device-to- device communication, and/or
- the apparatus comprises a mobility management entity.
According to further exemplary aspects of the present invention, there is provided: - a computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to the first aspect and/or any development or modification thereto,
- a computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to the second aspect and/or any development or modification thereto,
- a computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to the third aspect and/or any development or modification thereto, and
- a computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to the fourth aspect and/or any development or modification thereto,
By way of exemplary embodiments of the present invention, there are provided mechanisms for the initiation of sessions for device-to-device (D2D) communication using a local number format, local address format or a local URI format extension.
The device-to-device address may include a phone number, a session initiation protocol (SIP) address, or a uniform resource indicator (URI) such as a uniform resource locator (URL), a uniform resource name (URN) or similar.
By way of exemplary embodiments of the present invention, there is provided at least one of the following:
- the introduction of a local address format and a session initiation using such a local address format, which does not involve a non-local serving network node (e.g. SIP server) ,
- the introduction of a local address format, which allows session handling not to involve a non-local network node,
- the introduction of a session initiation process, which does not involve a non-local session server network node (e.g. SIP server) on the user plane, but instead includes added functionality to another local network node (e.g. MME) to handle session initiation in a local subnet domain, - the addition of a session initiation (e.g. SIP) handler to a local network node such as an MME so as to enable the local network node such as the MME to handle local D2D session initiation requests,
- the addition of a switch point to a device (e.g. application and/or software and/or firmware) that creates wide area session (initiation) requests (to the network) differently than D2D session (initiation) requests (i.e. the device switches the message either to the user plane or to the control plane) , - the addition of a switch point to a device (e.g. application and/or software and/or firmware) that detects and handles, in addition to wide area session (initiation) requests (from the network), D2D session (initiation) requests (from the network) (i.e. despite of detecting and handling these different requests differently, the device switches the session initiation message equally to the application layer for corresponding handling) ,
- the sending of the D2D session (initiation) request messages using the local address format not via the user plane, but via the control plane, e.g. using NAS (i.e. non-access stratum) messages, to the a local network node such as the MME,
- a network-sided control of D2D session initiation and D2D IP connectivity.
By virtue of exemplary embodiments of the present invention, there may be provided at least one of:
- faster session initiation times (i.e. reduced session initiation delay) in the local scope of e.g.
SAE/E-UTRAN or other cellular or wireless infrastructure,
- an efficient set-up of local D2D sessions without involving a non-local network node such as e.g. a SIP server in the Internet, - a new mode of operation for devices, which enables new types of service for users (being provided by the users themselves directly or by the operators or Internet Service Providers indirectly) ,
- reduction of load at the network access node (e.g. access router, base station, eNodeB, PDN GW, etc.), - efficient reuse of radio resources (coordination of D2D resources and e.g. cellular resources),
- IP connectivity in the local scope (in the context of an application of the present invention to LBO) .
According to embodiments of the present invention, device-to-device communication includes a direct communication between two or more devices.
Brief description of the drawings
In the following, the present invention will be described in greater detail by way of non-limiting examples with reference to the accompanying drawings, in which
Figure 1 shows the architecture of an E-UTRAN system according to Release 8,
Figure 2 shows the architecture of the E-UTRAN system for 3GPP accesses,
Figure 3 shows the different entities involved or impacted by device-to-device communication according to an embodiment of the present invention,
Figure 4 shows a schematic flow diagram of a method at a source-side device according to an embodiment of the present invention,
Figure 5 shows a signaling flow chart for session initiation using a global destination address,
Figure 6 shows a signaling flow chart for device-to- device session initiation using a local destination address according to an embodiment of the present invention,
Figure 7 shows an illustration of device connectivity on different protocols according to an embodiment of the present invention,
Figure 8 shows a schematic flow diagram of a method at a device according to an embodiment of the present invention,
Figure 9 shows a schematic flow diagram of a method at a network access node according to an embodiment of the present invention,
Figure 10 shows a schematic flow diagram of a method at a mobility management entity according to an embodiment of the present invention,
Figure 11 shows a schematic flow diagram of a method of device-to-device bearer setup according to an embodiment of the present invention,
Figure 12 shows a schematic flow diagram of a method at a device according to an embodiment of the present invention,
Figure 13 shows a schematic flow diagram of a method at a destination-side device according to an embodiment of the present invention, and
Figure 14 shows a schematic block diagram of different apparatuses and their interworking according to an embodiment of the present invention. Detailed description of embodiments of the present invention
The present invention is described herein with reference to particular non-limiting examples. A person skilled in the art will appreciate that the invention is not limited to these examples, and may be more broadly applied.
In particular, the present invention and its embodiments are mainly described in relation to 3GPP technologies being used as non-limiting examples for certain exemplary network configurations. In particular, an LTE (E-UTRAN) radio access network and corresponding standards (Release-8, Release-9, and LTE-Advanced) are used as a non-limiting example in this regard. As such, the description of the embodiments given herein specifically refers to terminology which is directly related thereto. Such terminology is only used in the context of the presented non-limiting examples, and does naturally not limit the invention in any way. Rather, any other network configuration or implementation may also be utilized as long as compliant with the features described herein.
In the following, various embodiments and implementations of the present invention and its aspects are described using several alternatives. It is generally to be noted that, according to certain needs and constraints, all of the described alternatives may be provided alone or in any conceivable combination (also including combinations of individual features of the various alternatives) .
Exemplary embodiments of the present invention enable the initiation of a D2D session in a 3GPP evolved system architecture (SAE) environment. Session initiation in the meaning used herein my be understood as an application layer process that may also be called session setup. According to exemplary embodiments of the present invention, session initiation or setup may be related to IP connectivity, connection management and bearer management processes on the other respective protocol layers. The exemplary embodiments provide a flexible approach to set up a D2D session within the 3GPP SAE (e.g. LTE) using a local number or local address format.
The above-mentioned local number or address format
(referred to as "local address format" hereinafter) may be based on any conceivable numbering or address scheme. For example, it may be based on a network access identifier (NAI) format or any other Internet address format, such as e.g. SIP URI (Session Initiation Protocol Uniform Resource Identifier) or http URL (Hypertext Transfer Protocol Uniform Resource Locator) or URN (Uniform Resource Name) . The local address format is based on the underlying address scheme, and is indicating the locality of the device or terminal having this local address format. The local scope, i.e. the presence in a local scope, may refer for example to Internet or Intranet or it may relate to a cell or a group of neighboring cells of a cellular communication system or any kind of subnet area of an underlying communication system (e.g. an access network) . For example, the locality of a target or destination device of a D2D communication is determined in relation to a source or originating device of a D2D communication. The modification for indicating locality may for example be a specific suffix and/or prefix and/or extension, and/or a keyword, which indicates a valid D2D format. For example, an Internet address (e.g. IP address) or a phone number with a special suffix or prefix may be used.
That is, any specifically designed predetermined format modification of a global address or numbering format may be used as local address format, as along as it is suitable for distinguishing between normal (i.e. nonlocal or global) calls and local calls.
For any of these known formats, embodiments of the present invention propose some extension for D2D communication purposes. This extension may, for illustrative purposes, be of the format NAI. D2D or, in more generic terms, of the format: usernameβrealm. D2D_keyword
Keyword proposals as mentioned above could be of the format : username@realm. D2D username@realm. direct usernameθrealm. local
Other keyword examples may apply equally, such as {short, device, fly, buddy, peer, fleet,...} or anything alike.
As an illustrative and non-limiting example, a network access identifier with a specific D2D extension is assumed as a local address format for the following description. This exemplary local address format may e.g. be denoted as "NAI. D2D", and may e.g. take the form "username@LTED2D. direct".
Device-to-device (D2D) communications may share the same band(s) used by the underlying communication system, in this case the cellular (e.g. LTE) network. As a result, it will be important to coordinate the D2D communication with the cellular network to be able to offer guarantees of service quality to the users in the cellular network. Thus, the D2D communication should be controlled and constrained by the cellular network.
Accordingly, exemplary embodiments of the present invention relate to a case of a D2D mode (including session initiation) with network support. The network support may in the case of a cellular network be provided by any network access node such as a base station (BS) or NodeB or an evolved eNodeB. According to exemplary embodiments of the present invention, the network access node thus supports messaging of the session initiation, connectivity set-up and resource control (e.g. reuse of licensed radio resources) , but is not involved in data transfer. That is, the supporting base station (BS) or NodeB or an evolved eNodeB is only involved on the control plane, and not on the user plane.
Exemplary embodiments of the present invention relate to session initiation which may exemplarily happen by IP protocols like the Session Initiation Protocol (SIP) . The session initiation according to exemplary embodiments of the present invention generally takes place on a local scope, e.g. within a local subnet area of e.g. Internet or Intranet or a cell or group of neighboring cells in a cellular network. To this end, a local serving network node such as for example a mobility management entity having knowledge of the location of the devices may serve as a session initiation server, i.e. in the case of SIP as a SIP (application) server, for local sessions, i.e. for sessions for local device-to-device calls.
Further, Session Description Protocol (SDP) messages may be delivered in the context of session initiation. Yet, an embodiment is that SDP and further session control messaging as signaling the media types will happen directly over the D2D bearer once established as a consequence of this session initiation process. Thus, more media components or more sessions could be added by directly communicating over the D2D connection.
Figure 3 shows the different entities involved or impacted by device-to-device (D2D) communication according to an embodiment of the present invention. The thus depicted situation exemplarily relates to the case of a cellular network, wherein the illustrated entities belong to a single cell thereof. These entities include the devices (D, such as the UEs shown in Figures 1 and 2) . Devices DD and DD+i as well as devices D1 and D1+i are engaged in a mutual D2D communication session, respectively. At the same time, a cellular link is active with respect to device Dk, and the base station (eNB 12) serves as a network access node to the (non-local) network e.g. Internet. In Figure 3, the dashed arrows indicate possible control links, i.e. links on the control plane e.g. for Radio Resource Control (RRC) messaging. By means of these control links between the devices being engaged in a D2D session and the network access node, network support for D2D communication may be provided. For initial D2D connection/session set-up, at least one or more of the following tasks are assumed to be performed by a device:
1. An association status with the eNodeB is checked. If associated with the eNodeB, the eNodeB is contacted for permission to engage in D2D communication. If granted, the device engages in the D2D mode with eNodeB support of this eNodeB.
2. If not associated with an eNodeB, it is scanned if an eNodeB (or any other network access node) is in the surrounding area, and it is associated therewith, if appropriate. Then, the device engages in the D2D mode with eNodeB support of the thus scanned eNodeB.
3. If no eNodeB (or any other network access node) is available, then the device engages in direct D2D mode without eNodeB support. However, this case may not allow reuse of licensed radio resources, and anyway its session set-up would converge to direct radio connectivity.
After the D2D mode has been initialized, network (eNodeB) control can be applied.
In general terms, the following features may be involved in such a network (eNodeB) control for D2D communication.
Control operations being available at the eNodeB as such, may for example include or being based on at least one of the following:
- interference metrics, - number of users in D2D communications, and number of active cellular links,
- communication/coordination with neighboring cells, - policies for setting up D2D communications instead of (or in addition to) cellular communications, when users are in direct range,
- handover from cellular to D2D when needed, and - handover back from D2D to cellular when needed.
Over the control interface for the network access node, which is provided by the dashed line links according to Figure 3, at least one of the following control operations may be provided.
- The eNodeB could reserve some (time, frequency, code sequence, spatial) resources to the D2D devices, which they schedule themselves.
- The eNodeB could remain in control of all resource or power allocations.
- The eNodeB could set constraints and operational regime for a D2D link.
- The eNodeB could make one device lead in the D2D communication and grant resources to that node. - The eNodeB could request measurements. One probable measurement could be the D2D link quality. It is to be noted that such measurements depend on the technique selected for the D2D radio interface.
- The eNodeB could cancel a D2D link. The eNodeB could re-establish the communication via cellular links. Thus, the eNodeb could remain passive after just initiating the D2D session.
All or some of the above control operations could be implemented by way of D2D radio bearer set-up, as described below.
In the following, eNodeB-supported session set-up for D2D communication (i.e. D2D mode) using a local address format will be described in detail. The network access node (e.g. the base station or eNodeB) can identify a call as a D2D call by detecting a local address format, e.g. a specific Network Address Identifier (NAI) format for D2D communications (local number, NAI. D2D), of the destination device for communication. In this case, the source device, e.g. UEl, calls the destination device, e.g. UE2, by a session setup request such as e.g. a SIP INVITE message using the local NAI. D2D of UE2. This leads to the set-up of a D2D bearer between UEl and UE2 instead of evolved packet system (EPS) bearers, which may be effected by the local network access node (e.g. the base station or eNodeB) . Thus, the set-up procedure does not involve a (non-local) SIP server, which leads to faster setup times.
At the source device, e.g. UEl, there is provided a switch point (in case of SIP protocol session initiation a SIP switch point) for the new NAI. D2D format e.g. in the device. The switch point in the device handles the addresses of local address format differently than the addresses of normal (SIP) addresses.
Figure 4 shows a schematic flow diagram of a method at a source-side device according to an embodiment of the present invention. This flow diagram refers to the source device originating the session initiation process. According thereto, an exemplary SIP message representing a session initiation (set-up) request message is created, and a corresponding SIP destination address is created depending on user input or selection by service software. For the further process is to be distinguished whether or not the thus created destination address contains a D2D extension, i.e. whether or not the destination address is of local scope (S401) . If so (i.e. YES in S401), the local address (e.g. NAI. D2D or, in more generic terms, username@realm.D2D keyword) is used for session initiation taking place over the control plane. Namely, the local address is used for creating a corresponding request message (S402), a control plane (e.g. non-access stratum, NAS) request message is sent locally (S403) to a corresponding service access point (e.g. NAS SAP), and the local address is resolved at a local serving network node such as e.g. a mobility management entity MME (S404), which is thus enabled to search for the destination device. Stated in other words, the application layer writes the SIP message to the application programming interface (API) for the firmware of the UE, which receives the e.g. SIP INVITE message in API function call in a proper format having the destination username (i.e. SIP level address), and the function call further includes instructions to place this message to the NAS SAP (i.e. non-access stratum service access point) instead of to the TCP/IP port. The firmware writes to the NAS SAP, from where the NAS protocol software processes the NAS protocol headers, copies the application data inside the NAS container, and the delivery is handled by the cellular protocols to the MME. Details of these control plane procedures are given in connection with Figure 6 below.
Otherwise, if not (i.e. NO in S401), the non-local global/normal address (e.g. NAI or, in more generic terms, usernameβrealm) is used for session initiation taking place over the user plane. Namely, the global address (e.g. username@realm) is used for creating a corresponding request message (S405) , a user plane request message is sent to a local packet data network (PDN) gateway (GW) (S406) and further to a non-local SIP server (S407) . Stated in other words, the application layer writes the SIP message to the application programming interface (API) for the firmware of the UE, which receives the e.g. SIP INVITE message in API function call in a proper format having the destination username (i.e. SIP level address), and the function call further includes instructions to place this message to the TCP/IP port. The firmware identifies what is the TCP port number to open and which IP address to use. Then, the TCP/IP socket or such is openend, and SIP INVITE message is transmitted there in a TCP/IP datagram. Details of these user plane procedures are given in connection with Figure 5 below.
Hence, when the device creates local destination address (i.e. a destination address with a D2D extension), it will not use the NAI format and send the request over the user plane (UP), but it will use the NAI. D2D format and send the request e.g. using a Non-Access Stratum (NAS) control plane (CP) message.
Figure 5 shows a signaling flow chart for session initiation using a global destination address (URI, URL, URN or such) . This user plane procedure for session initiation for non-local communication comprises, the establishment of a radio resource control (RRC) connection between the source device UEl and eNodeB, the set-up of an SAE bearer between the source device UEl and the PDN gateway, the sending of a SIP INVITE message using the global address on the user plane from the source device UEl via the PDN GW to a SIP application server (SIP AS) , the routing of this SIP INVITE message from the PDN GW to the non-local destination device UE2, and the returning of SIP response messages from the destination device UE2 to the source device UEl over the SIP application server. Here, the PDN GW acts as the IP level gateway and router, and it does not process the SIP application messages.
Figure 6 shows a signaling flow chart for device-to- device session initiation using a local destination address (modified URI, URL, URN or such, e.g. the NAI. D2D) according to an embodiment of the present invention. According to Figure 6, an internal arrangement of the individual devices UEl and UE2 is indicated using an illustration of an application layer "appl", a non- access stratum layer "NAS" and a radio resource control layer "RRC", and an internal arrangement of the eNodeB is indicated using a non-access stratum layer "NAS" and a radio resource control layer "RRC". According to Figure
6, the local scope comprises the devices UEl and UE2, the eNodeB, the MME and the PDN gateway, while the SIP application server (SIP AS) represents a non-local network node. It may be seen that the entire procedure runs in the local scope, and the SIP server is not involved.
After establishment of a radio resource control (RRC) connection between the source device UEl and eNodeB and set-up of an SAE bearer between the source device UEl and the PDN gateway, the actual session initiation procedure according to exemplary embodiments of the present invention takes place as follows.
A local NAI. D2D address format of the destination device UE2 is created by the source device UEl e.g. by a user selecting the address format or by the application picking up an address format in preferred order. Then, the source device UEl sends a session set-up request e.g. in the form of a SIP [NAI. D2D, invite] message to the MME. This may e.g. be effected by using a NAS c-Plane message (as shown in the box below the respective SIP INVITE message) , which is forwarded via the eNodeB to the MME. In other words, the application of device UEl does not send the request to the u-Plane port (e.g. TCP/IP port or UDP/IP port) , but it sends it to the NAS service access point (NAS SAP) instead.
In order to enable that the MME can identify the message as a session initiation (e.g. SIP) message, a session initiation protocol (e.g. SIP) identifier may be added to the message already at this point. Thereby, it may be denoted that a SIP message is nested within a message container of another protocol. The request is then forwarded by the eNodeB to the mobility management entity (MME) using the standard protocols. Typically, NAS messages (as message containers) are delivered being encapsulated in the RRC messages between the UE and the eNB and encapsulated in the Sl Application protocols between the eNB and MME. The transport between eNodeB and MME may for example be an IP tunnel.
The MME acts as a session initiation server functionality (e.g. similar than a SIP server) . In order to be able to handle session initiation messages (e.g. SIP messages inside the NAS container containing a SIP protocol identifier) , the MME is provided with a corresponding session initiation handler, e.g. with a SIP handler. The SIP handler (which may also be referred to as a "light SIP server") receives the SIP [NAI. D2D invite] message, and knows where to find the destination device UE2 under the mobility management of that MME, if it is in the same subnet or if it is associated to one of the eNodeB' s in the neighborhood. In other words, the MME knows the (SIP) presence and knows the address information, that is e.g. dynamic Mobile IP addresses, of the devices attached to it. Alternatively, the MME may create its own subnet and give new IP addresses from that local subnet scope for source device UEl and destination device UE2. (These IP addresses would serve D2D IP connectivity only.) The MME then forwards the SIP [NAI. D2D invite] message to the destination device UE2. This may e.g. be effected by using a NAS c-Plane message (as shown in the box below the respective SIP INVITE message), which is forwarded via the eNodeB to the destination device UE2.
The destination device UE2 detects, once it receives a NAS message (i.e. a NAS message container containing a SIP message) , from the SIP protocol identifier of that
NAS message that it contains a SIP message, and forwards the SIP part of the NAS message to the application layer, i.e. to its SIP handler. Thus, the destination device UE2 acts on the SIP INVITE message as if it were received from the SIP server on the u-plane, although it was received in the NAS message on the c-plane. Then, the destination device sends a SIP response message to the MME, and the MME forwards the SIP response to source device UEl.
After that, the MME requests the eNodeB to set up a D2D radio bearer by issuing a D2D radio bearer set-up request. The eNodeB sets up the D2D bearer between the source device UEl and the destination device UE2. After the successful D2D bearer set-up the two devices UEl and UE2 can communicate directly with each other, and the eNodeB confirms the successful D2D bearer setup to the MME. The execution of the D2D radio bearer set-up as such is not covered by the present invention. It may be performed in any conceivable manner, e.g. as shown in Figure 11. Figure 11 shows a schematic flow diagram of a method of device-to-device bearer setup according to an embodiment of the present invention.
At the same time, when the D2D radio bearer set-up is completed, IP connectivity may be provided, and a SIP session for D2D communication between UEl and UE2 can be established. After that, D2D data may be directly exchanged between devices UEl and UE2.
Thereafter, any Session Description protocol or session control may happen on the D2D bearer directly. The peer devices may initiate further sessions, terminate sessions or change their parameters and/or media types on that D2D connection directly.
Using the above described procedure according to exemplary embodiments of the present invention, the session can be initiated without involving a SIP server. Thus, the additional delay from involving a SIP server can be avoided.
Stated in other words, according to embodiments of the present invention, the eNodeB receives NAS messages and forwards them to the MME, but it does not process application layer messages as SIP. The session protocol identifier in the NAS message is actually for the MME to know that the embedded message is SIP. This is needed because MME will receive NAS messages for various purposes, e.g. security and authentication. The SIP protocol identifier lets MME pass the SIP message extracted from inside the NAS message to the SIP handler. (Other NAS contents, e.g. authentication, will go to the authentication protocol software) .
The eNodeB may detect the SIP protocol identifier in the NAS message, so that it knows to pass that part of the NAS message to the MME. Typically, all NAS messages will go from the UE to the MME without eNodeB actively processing them. Vice versa, NAS messages from the MME will go to the UE without eNodeB actively processing them. That is, the eNodeB just delivers the NAS messages (e.g. inside an RRC message container) to the UE. Yet, as another option, the eNodeB itself could process the application layer protocol (SIP) and detect the address format of local scope.
Figure 7 shows an illustration of device connectivity on different protocols according to an embodiment of the present invention. Namely, Figure 7 illustrates the connectivity between different protocol layers at the two above-mentioned devices engaged in D2D communication.
The session (e.g. SIP) messages are sent from the application layer of the devices. The bearer setup is done at the RRC layer, and the IP connectivity is between the IP layers (i.e. TCP/UDP) at the devices.
Although not mentioned beforehand, it is to be noted that IP connectivity (previously referred to in the context of the Local Breakout concept) might be preferred even in the D2D communication case (where it is not mandatorily needed) . IP connectivity can virtually be established between the peer devices. This means that the MME delivers local scope IP addresses (i.e. D2D IP addresses) to source device UEl and destination device UE2 for D2D communication, but there will be no routing function needed. However, IP addresses for D2D communications are not necessarily needed, because after the set-up the devices directly know the needed Logical Channel ID (LCID) and know the allocated resources for (D2D) communication. However, having IP addresses in use makes the protocol stack and connectivity more consistent to the normal (widea area) operation. This consistency is beneficial in certain operations.
The virtual IP connectivity can be established by the MME and may be carried inside the control plane (e.g. NAS) messages so that a D2D bearer request message includes IP addresses for source device UEl and destination device UE2 embedded inside the message elements. While setting up the D2D bearer, the eNodeB will also inform the devices about their IP addresses inside the embedded control plane (e.g. NAS) message. That is, the source device UEl will get to know its own IP address and the IP address of its peer entity UE2, whom it invited for a (SIP) session. The destination device UE2 will also get to know its own IP address and the IP address of its peer entity UEl. After the setup, the devices have readily available source IP address and destination IP address, D2D bearer identity (D2D BID) and logical channel ID (LCID) available for D2D communications.
The MME may get the IP addresses for D2D communication between source device UEl and destination device UE2 from an assigned local pool (e.g. discovery from a DHCP), or it may itself assign addresses for them as long as they do not conflict with any other IP address in the same subnet, i.e. local scope. While different IP assignment strategies can be used, it is preferable to have a separate pool of addresses available at the MME so that the MME creates and manages its own subnet. According to certain exemplary embodiments of the present invention, the following messages and their respective contents are provided.
1) A session invitation message, e.g. SIP INVITE, with the contents of a local address format, e.g. a new NAI = NAI. D2D. As an alternative, a new SIP message e.g. named SIP_D2D_invite could be defined.
The NAI. D2D format can have for example the following format "username@LTED2D. direct" .
2) A control plane message, e.g. a NAS message, that contains the SIP message [D2D, invite] and that is directed to the MME.
Here it is sufficient to have a protocol identifier (e.g. NAS message header) , which tells the MME that the message is a SIP message. The IP address fields could be embedded as NAS message fields and not directly as fields of the RRC message.
3) A D2D bearer request/confirmation message concerning radio bearer set-up request for D2D communication.
Here, it is needed to have IP addresses to tell eNodeB as to which devices are involved. Alternatively, if IP addresses are not used or before the IP addresses are assigned, the UE IDs (e.g. S-TMSI (Supporting Temporary Mobile Subscriber identity) ) can be used. The IP address fields could be embedded as NAS message fields.
4) A D2D bearer setup message concerning radio bearer set-up for D2D communication. Here, c-RNTI (cell Radio Network Temporary Identifier) of source device UEl and c-RNTI of destination device UE2, and possibly a new c-RNTI (cell Radio Network Temporary Identifier) for the D2D connection itself are needed. Then, Bearer ID and logical channel ID for the D2D connection are needed. All of these are given by the eNodeB. It should be noted that multiple D2D bearers may be set up by a single setup message simultaneously, if necessary.
Here, it is also needed to deliver the 'own' IP address of UEl and the IP address of the peer UE2 to UEl. And it is needed to deliver the 'own' IP address of UE2 and the IP address of the peer UEl to UE2.
The format of this message may e.g. be address_type = {own, peer}, address format {IPv4, IPv6} and IP address {syntax known}. Also, an option for multiple peers may be added, i.e. a set of peer UE addresses will be listed. This is needed e.g. in multiparty SIP calls.
5) A D2D Bearer including at least one of bearer ID, c- RNTI, and logical channel ID.
According to certain exemplary embodiments of the present invention, the following features are optional.
As regards the creation and/or detection of a local address format, a local address or number list may be maintained at the MME. The local address or number may be a part of subscription information of the devices in the home subscription server (HSS) , from where the MME may fetch it. The MME may store the local number or address temporarily, or may even deliver it to the eNodeB for temporal storing.
The device connects to another device using the local address format (e.g. the NAI. D2D format), without performing a complete call setup via the external (core) network such as e.g. the Internet. This option assumes that either the local number or address is used within the network of one operator, or that the local numbers or addresses are stored/registered with the HSS of an operator. If the destination device is not in the local number or address list, the source device may get an indication of denial such as e.g. a "D2D connection not possible" message, and it can then alternatively initiate a connection set-up using the normal SIP session set-up and address format, as illustrated in Figure 5 above.
The available local numbers or addresses in the vicinity of a device can be advertised by the eNodeB as an (operator) service, or they can be printed/displayed on a device with D2D connectivity (e.g. media server) . Thereby, the discovery of local numbers or addresses in a local scope such as a cell may be accomplished.
For obtaining local numbers or addresses for later use, the normal/global number or address may be converted to a local number or address. When IMS (IP Multimedia Subsystem) equipment is available, this may be effected e.g. by a call state control function (CSCF) . Then, the device obtains the local number or address from the CSCF, and it can use that local number or address for subsequent D2D communication attempts.
Alternatively, the user of the device may store the local addresses in the address book as extensions of the global addresses of the respective contacts. (This may simply be a choice of "allow local calls", and the software knows to convert the address respectively.)
For session initiation, the use of the Session Initiation Protocol (SIP) is described as one illustrative and non- limiting example. When SIP is used, SIP messaging may include SDP (Session Description Protocol) fields indicating e.g. media types and media formats of the session, i.e. of the traffic to be exchanged in the session .
In the following, LBO-internal session set-up for D2D communication (i.e. D2D mode) in LTE/SAE using a local address format will be described.
As mentioned above, Local Breakout (LBO) provides a concept, where in addition to the normal wide area IP connectivity and setting up of the SAE bearer, the MME additionally sets up a local SAE radio bearer between the device and the eNodeB. This set-up may happen at the initial request by the device. In the LBO concept, the eNodeB is further proposed to contain some networking protocols e.g. for local scope DHCP discovery to find a local gateway to which it can attach the device to. IP connectivity between the device and the local gateway offers the opportunity for the device to make local IP calls inside the local subnet via the local gateway. Further, it is possible for the device to access the global Internet, if the local gateway has such functionality. This however, may make the local gateway a performance bottleneck.
The LBO solution does not yet include a D2D communication option, as described hereinbefore. Accordingly, the basic ideas underlying the above- described eNodeB-supported set-up for D2D communication are also applicable to the LBO concept. Namely, the MME may serve the session set-up (because control plane signaling is used) , and may avoid involvement of wide are core network, which makes response times for local calls (including D2D calls) shorter. Thus, the D2D set-up according to embodiments of the present invention may also be implemented within an LBO framework.
The MME in LBO sets up SAE bearers, but it can not set up the D2D bearer. Thus, according to embodiments of the present invention, the MME sends a request to the eNodeB to set up a D2D bearer between the devices. The eNodeB sets up a D2D radio bearer, which can also be considered as a special SAE level D2D bearer in the SAE bearer model. Thus, the bearers may be named D2D SAE bearer and D2D radio bearer, but may shortly be called D2D bearers. The service data units (SDUs) delivered on the D2D bearer are mapped (one-to-one) to a logical channel with an LCID. The LCID is allocated by the eNodeB and is informed to both devices UEl and UE2.
While an overall (system level) view on exemplary embodiments of the present invention has been given above, procedures at individual entities being involved or impacted are given in the following.
Figure 8 shows a schematic flow diagram of a method at a device according to an embodiment of the present invention . The exemplary method according to Figure 8 may for example be executed at a user equipment UE acting as a source device of D2D communication.
According to the exemplary method depicted in Figure 8, in S801a, a destination address for session initiation is created in that it is decided by the user or by the application whether an address of a destination device for device-to-device communication is of a local address format (e.g. NAI. D2D) . If so (i.e. YES in S801b) , a session initiation request (e.g. SIP INVITE) for device- to-device communication using the created local address format of the destination device is created (S802), and the thus created session initiation request (e.g. SIP INVITE) is written to a corresponding service access point of the control plane (e.g. NAS SAP), and is further sent on the control plane to a local serving network node such as a MME (S804) . The sending of S804 may comprise a sending of a control plane message such as a NAS message, which is sent to the MME via an eNodeB. As mentioned above, a session-initiation-protocol identifier (e.g. a SIP identifier) may be added to the thus created NAS message for message type detection at the MME (S803) ) .
Additionally, in S805, a local device-to-device bearer to the destination device may be established upon a corresponding request from the eNodeB. Thereupon, a device-to-device IP connectivity (as a non-limiting example for any kind of traffic transmission connectivity) in S806, and a device-to-device session may finally be established in S807.
On the other hand, if the destination device address is detected to be not of a local address format (i.e. NO in S801b) , IP connectivity is established between the user equipment and the (non-local) network. In contrast to the local D2D session initiation process of the left-hand branch of Figure 8, the previous establishment of IP connectivity is necessary for non-local session initiation. This is because otherwise the user equipment is not able to send any message, to connect to e.g. web services, or in this case to establish a session with another user equipment in non-local scope. Then, in S809, a session initiation request (e.g. SIP INVITE) using the global/normal address format of the destination device is created, is written to the TCP/IP or UDP/IP port of the user plane, and is sent to the non-local SIP server (S810) . Thereupon, in S811, a (non-local) session may finally be established e.g. between the present user equipment and another user equipment or between the present user equipment and an Internet Service Provider (ISP) .
Figure 9 shows a schematic flow diagram of a method at a network access node according to an embodiment of the present invention.
The exemplary method according to Figure 9 may for example be executed at a base station (BS) or NodeB or eNodeB acting as a network access node in the local scope of D2D communication.
According to the exemplary method depicted in Figure 9, in S901, a control plane message (e.g. NAS message) including a session set-up request (e.g. SIP INVITE) for device-to-device communication is received from the source device or an MME (depending on the phase of session initiation, cf. Figure 6) . In S902, the control plane message (e.g. NAS message) is detected, i.e. the message type of the session initiation protocol (SIP) is detected. In S903, the control plane message (e.g. NAS message) including the session initiation request (e.g. SIP INVITE) for device-to-device communication is forwarded (i.e. delivered) to another local serving network node such as a MME (if received from the source device) or to the destination device (if received from the MME) .
In S902a, a session initiation protocol identifier (e.g. a SIP identifier) may be identified in thus received the NAS message embedding the session initiation request (e.g. SIP INVITE), if added thereto in an adding operation at the device side.
By way of these operations, the session initiation request (e.g. SIP INVITE) is transparently passed from the source device through the network access node to the competent local serving network node (e.g. MME) .
Alternatively, the direction of passing-through may also be vice versa, i.e. from the competent local serving network node (e.g. MME) through the network access node to the destination device.
Additionally, in S905, a device-to-device bearer between the source device and the destination device for device- to-device communication may be set up upon receipt (in S904) of a device-to-device bearer set-up request from the competent local serving network node (e.g. MME) .
In the context of bearer set-up, after receipt of the D2D bearer set-up request in S904, IP addresses for D2D communication (i.e. the own IP address and the peer IP address) may be received, the D2D bearer may be acknowledged to the MME, and the IP addresses may be distributed to the source device and the destination device. That is, IP connectivity may be provided.
Figure 10 shows a schematic flow diagram of a method at a mobility management entity according to an embodiment of the present invention.
The exemplary method according to Figure 10 may for example be executed at a local serving network node acting as a mobility management entity (being responsible for devices of a D2D communication.
According to the exemplary method depicted in Figure 10, in SlOOl, a session initiation request (e.g. SIP INVITE) for device-to-device communication is received from a source device. The receiving may comprise a receiving of a control plane message (e.g. NAS message) including a session set-up request (e.g. SIP INVITE) from an eNodeB.
In S1002, a session initiation protocol identifier (e.g. a SIP identifier) may be identified in thus received the NAS message embedding the session initiation request (e.g. SIP INVITE), if added thereto in an adding operation at the device side. Thereby, in the SIP example case, the MME may identify the message as a SIP message to be passed to a SIP handler, and the MME may thus server as a (light) SIP server.
In S1003, an address of a destination device for device- to-device communication is detected (by a SIP handler at the MME) in the thus received session set-up request (e.g. SIP INVITE) to be of a local address format (e.g. NAI. D2D) . In S1004, the local address format is resolved for locating the destination device (with a possible help from the HSS) , and the destination device may be searched in the respective subnet (i.e. local scope) . This means that, based on the destination username, the MME acting as (light) SIP server may search the destination device, i.e. its TMSI and/global IP address, so that it can contact the destination device for session initiation, e.g. by a control plane (NAS) message. Then, a corresponding session initiation request (e.g. SIP
INVITE) for device-to-device communication is further delivered (S1005) on the control plane to the destination device of D2D communication. The delivery of S1005 may comprise a sending of a control plane message such as a NAS message, which is sent to the destination device vie the eNodeB.
Additionally, in S1006, a device-to-device bearer set-up request may be issued to a local serving network node such as an eNodeB acting as network access node.
Stated in other words, according to embodiments of the present invention, the MME can act as a SIP server, search for the peer (i.e. the destination device) in the local subnet scope, create IP addresses for the D2D peer devices, provide IP connectivity between the peers, and request the eNodeB to set up a D2D bearer. The MME will forward the SIP message using identifiers of the destination device UE2 (either its TMSI or IP address or both) via the eNodeB to the destination device UE2. At the MME request, the eNodeB will set up the bearers, also D2D bearers, and will deliver the IP addresses to UEl and UE2, and the SIP message will reach the destination device UE2, in the embedded NAS message. Figure 12 shows a schematic flow diagram of a method at a device according to an embodiment of the present invention .
The exemplary method according to Figure 12 may for example be executed at a user equipment UE acting as a destination device of D2D communication.
According to the exemplary method depicted in Figure 8, in S1201, a session initiation request (e.g. SIP INVITE) for device-to-device communication is received from a MME on the control plane. The receiving may comprise a receiving of a control plane message (e.g. NAS message) including a session set-up request (e.g. SIP INVITE) from an eNodeB.
In S1202, a session initiation protocol identifier (e.g. a SIP identifier) may be identified in thus received the NAS message embedding the session initiation request (e.g. SIP INVITE), if added thereto. Thereby, in the SIP example case, the UE2 may identify the message as a SIP message to be passed to a SIP handler at the application layer. Then, in S1203, the SIP INVITE message is processed as it were received on the user plane. Namely, the SIP INVITE message will be processed to establish the SIP session between UEl and UE2. Further communications about the sessions between UEl and UE2 may happen via the D2D interface.
Additionally, in S1204, a local device-to-device bearer to the destination device may be established upon a corresponding request from the eNodeB. Thereupon, a device-to-device IP connectivity (as a non-limiting example for any kind of traffic transmission connectivity) in S1205, and a device-to-device session may finally be established in S1206. While Figure 12 only illustrates a method in the case of a local D2D session initiation on the control plane according to embodiments of the present invention, i.e. user equipment UE2 acting as a destination device of D2D communication, the user equipment UE2 may likewise act as destination device of a normal (i.e. global or non-local) communication, i.e. in the case of a non-local session initiation on the user plane. The different operations in these two cases are illustrated in Figure 13.
Figure 13 shows a schematic flow diagram of a method at a destination-side device according to an embodiment of the present invention.
That is, in case of a local D2D session initiation on the control plane according to embodiments of the present invention, the device (e.g. application and/or firmware and/or software) of the destination device UE2 reads the non-access stratum service access point NAS SAP, to where the NAS protocol software has processed message contents after handling the NAS protocol headers, and it copies (i.e. passes) the application data via the application programming interface (API) to the application software capable of handling session initiation e.g. by way of the Session Initiation Protocol, for further processing (e.g. the SIP INVITE message) . Otherwise, in case of a nonlocal session initiation on the user plane, the device (e.g. application and/or firmware and/or software) of the destination device UE2 receives a TCP connection request, and the TCP/IP port is open for the application software. Hence, the application layer session initiation protocol receives e.g. SIP INVITE message in an API function call from the TCP/IP port. Although in the foregoing embodiments of the present invention have been described mainly with reference to methods, procedures and functions, corresponding embodiments of the present invention also cover respective apparatuses, network nodes, including both software and/or hardware thereof.
Respective exemplary embodiments of the present invention are described below referring to Figure 14, while for the sake of brevity reference is made to the detailed description of respective corresponding methods and operations according to Figures 4 to 12, respectively.
Figure 14 shows a schematic block diagram of different apparatuses and their interworking according to an embodiment of the present invention.
The thus depicted apparatuses may for example be implemented in or by a (source and/or destination) device or user equipment, a base station or an evolved radio access node (e.g. eNodeB) in an evolved broadband radio access network (e.g. LTE, E-UTRAN), and a mobility management entity MME, respectively. Hence, such a device or user equipment, such a base station or an evolved radio access node (e.g. eNodeB), and such a mobility management entity MME represent particular machines on which a corresponding software implementation of the respective embodiments may be stored and/or executed. Although Figure 14 contains four distinct apparatuses (i.e. UEl, UE2, eNodeB/BS and MME), any one of these apparatuses represents an autonomous entity according to respective embodiments of the present invention, while their interworking entirety or any conceivable combination thereof represents a system according to an embodiment of the present invention. In Figure 14, the solid line blocks are basically configured to perform the respective operations. The entirety of blocks is basically configured to perform the methods and operations as described above, respectively. With respect to Figure 14, it is to be noted that the individual blocks are meant to illustrate respective functional blocks implementing a respective function, process or procedure, respectively. Such functional blocks are implementation-independent, i.e. may be implemented by means of any kind of hardware or software, respectively. The lines/arrows interconnecting individual blocks are meant to illustrate an operational coupling there-between, which on the one hand is implementation- independent (e.g. wired or wireless) and on the other hand may also comprise an arbitrary number of intermediary functional entities not shown.
Further, in Figure 14, only those functional blocks are illustrated, which relate to any one of the above- described methods, procedures and functions. A skilled person is deemed to acknowledge the presence of any other conventional functional blocks required for an operation of respective structural arrangements, such as e.g. a power supply, a central processing unit, respective memories or the like.
According to the exemplary embodiment depicted in Figure 14, the thus depicted source device or user equipment comprises a (software) switch (or in the exemplary SIP case a SIP switch) , a creator and an adder constituting a format handler or in the exemplary SIP case a SIP format handler) , and a transmitter and/or receiver constituting a transceiver TRX. Stated in general terms, the (address format) creator represents means creating an address of a destination device for device-to-device communication to be of a local address format, and for creating a session initiation request (e.g. SIP INVITE) for device-to-device communication using the created local address format of the destination device, and the transceiver represents means for sending the created session initiation request on a control plane to a local serving network node such as e.g. the depicted MME. The transceiver may also represent means for sending the created session initiation request using a control plane message (e.g. NAS message) to a local serving network node such as e.g. the depicted eNodeB.
The adder represents means for adding a session initiation (e.g. SIP) protocol identifier e.g. to a thus created NAS message. A D2D bearer establisher (not shown) represents means for establishing a local device-to- device bearer to the destination device upon request e.g. from the eNodeB.
In general, the various embodiments of the device or user equipment may include, but are not limited to, cellular mobile phones, multimedia devices, communicators, mini- laptops, personal digital assistants (PDAs) having wireless communication capabilities, portable computers having wireless communication capabilities, image capture devices such as digital cameras having wireless communication capabilities, gaming devices having wireless communication capabilities, music storage and playback appliances having wireless communication capabilities, Internet appliances permitting wireless Internet access and browsing, as well as portable units or terminals that incorporate combinations of such functions .
According to the exemplary embodiment depicted in Figure 14, the thus depicted network access node (i.e. eNodeB or BS) comprises a detector, a transmitter and/or receiver constituting a transceiver TRX (which is depicted as being separated for two transmission directions, which is however only for illustrative purposes) , an identifier, and an D2D bearer processor.
Stated in general terms, the detector represents means for detecting, in a received control plane message (e.g. NAS message) , a SIP protocol identifier, and the transceivers represent means for receiving and/or sending a control plane message including a session initiation request for device-to-device communication. On the one hand, the transceiver on the left-hand side may represent means for receiving a control plane message including a session initiation request for device-to-device communication (from the source device) , and the transceiver on the right-hand side may represent means for forwarding the control plane message including the session initiation request for device-to-device communication (to the MME) . On the other hand, the transceiver on the right-hand side may represent means for receiving a control plane message including a session initiation request for device-to-device communication (from the MME), and the transceiver on the right-hand side may represent means for forwarding the control plane message including the session initiation request for device-to-device communication (to the destination device) . The identifier represents means for identifying a session initiation protocol identifier in the control plane message. The eNodeB or BS as such may represent means for transparently passing though a session initiation request (e.g. SIP INVITE) between source/destination device and the MME.
The D2D bearer processor may represent means for setting up a device-to-device bearer between source and destination devices for device-to-device communication upon receipt of a device-to-device bearer set-up request e.g. from the MME.
According to the exemplary embodiment depicted in Figure 14, the thus depicted local serving network node, e.g. the mobility management entity MME, comprises a detector, a resolver and a deliverer and an identifier constituting a handler (or in the exemplary SIP case a SIP handler) , a transmitter and/or receiver constituting a transceiver TRX, and also an D2D bearer issuer.
Stated in general terms, the transceiver represents means for receiving a session initiation request (e.g. SIP INVITE) on a control plane from the device, the detector represents means for detecting, in the received session initiation request, an address of a destination device for device-to-device communication to be of a local address format, the resolver represents means for resolving the local address format for locating the destination device and for searching for the destination device, the deliverer represents means for delivering a session initiation request (e.g. SIP INVITE) for device- to-device communication further using the detected local address format of the destination device, and the transceiver also represents means for sending it to the destination device. The transceiver may also represent means for receiving the session initiation request using a control plane message (e.g. NAS message) from the eNodeB, and/or means for sending the created session initiation request using a control plane message (e.g. NAS message) to a local network node such as e.g. the depicted eNodeB.
The identifier represents means for identifying the received session initiation request as a session initiation protocol invitation message by means of a session initiation protocol identifier in the received NAS message. The D2D bearer issuer represents means for issuing a device-to-device bearer set-up request to a local serving network node such as e.g. the depicted eNodeB.
According to the exemplary embodiment depicted in Figure 14, the thus depicted destination device or user equipment comprises an identifier, a session initiation (e.g. SIP) handler, a transmitter and/or receiver (TRX), and an D2D bearer establisher.
The transceiver represents means for receiving a control plane message (e.g. NAS message) including a session initiation request (e.g. SIP INVITE) for device-to-device communication from a local network node. The identifier represents means for identifying, in the received control plane message, a session initiation protocol (SIP) identifier, and the SIP handler represents a session processor or, stated in other words, means for processing the session initiation request for initiating device-to- device communication with a source device, which may include passing the session initiation request to an application (e.g. application layer) for handling device- to-device session initiation.
The D2D bearer establisher represents means for establishing a local device-to-device bearer to the source device upon request from the local network node (similar to that of the source device, although not shown there) .
It is to be noted that, only for illustrative purposes in order not to hamper the lucidity of Figure 14, the sending of a session set-up request or control plane message using a global/normal address from the device or user equipment, and the sending of any messages towards the destination device are not illustrated.
Although the above illustrative description of embodiments of the present invention refers to the case of a device-to-device communication of two devices, a device-to-device communication may equally include three or more devices (i.e. multi-party sessions) . In such a case, one or more of the involved devices may start the multi-party session initiation, while the one or more remaining devices on local scope act as destination devices, respectively.
In general, it is to be noted that respective functional blocks or elements according to above-described aspects can be implemented by any known means, either in hardware and/or software, respectively, if it is only adapted to perform the described functions of the respective parts. The mentioned method steps can be realized in individual functional blocks or by individual devices, or one or more of the method steps can be realized in a single functional block or by a single device. Furthermore, method steps and functions likely to be implemented as software code portions and being run using a processor at one of the entities are software code independent and can be specified using any known or future developed programming language such as e.g. Java, C++, C, and Assembler. The operation system may include linux, unix, Symbian, Windows, Java J2ME etc. Method steps and/or devices or means likely to be implemented as hardware components at one of the entities are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS, CMOS, BiCMOS, ECL, TTL, etc, using for example ASIC components or DSP components, as an example. Generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the present invention. Devices and means can be implemented as individual devices, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device is preserved. Such and similar principles are to be considered as known to those skilled in the art.
Software in the sense of the present description comprises software code as such comprising code means for performing the respective functions, as well as software (or a computer program or a computer program product) embodied on a tangible medium such as a computer-readable storage medium having stored thereon a respective data structure or code portions or embodied in a signal or in a chip, potentially during processing thereof.
Generally, for the purpose of the present invention as described herein above, it should be noted that - an access technology may be any technology by means of which a user equipment can access an access network (e.g. via a base station, access point or generally an access node) . Any present or future technology, such as WLAN (Wireless Local Access Network) /WiFi, WiMAX (Worldwide Interoperability for Microwave Access) , BlueTooth, Infrared, Ultra Wideband (UWB) and the like may be used; although the above technologies are mostly wireless access technologies, e.g. in different radio spectra, access technology in the sense of the present invention may also imply wirebound technologies, e.g. IP based access technologies like cable networks or fixed lines but also circuits switched access technologies; access technologies may be distinguishable in at least two categories or access domains such as packet switched and circuit switched, but the existence of more than two access domains does not impede the invention being applied thereto, - an access network may be any device, apparatus, unit or means by which a station, entity or other user equipment may connect to and/or utilize services offered by the access network; such services include, among others, data and/or (audio-) visual communication, data download etc . ; - a user equipment may be any device, apparatus, unit or means by which a system user may experience services from an access network such as a mobile phone, personal digital assistant PDA, multimedia device, communicator, laptop or computer; - method steps likely to be implemented as software code portions and being run using a processor at a network element or terminal (as examples of devices, apparatuses and/or modules thereof, or as examples of entities including apparatuses and/or modules therefor) , are software code independent and can be specified using any known or future developed programming language as long as the functionality defined by the method steps is preserved;
- generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the invention in terms of the functionality implemented;
- method steps and/or devices, apparatuses, units or means likely to be implemented as hardware components at a terminal or network element, or any module (s) thereof, are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), TTL (Transistor-Transistor Logic), etc., using for example ASIC (Application Specific IC (Integrated Circuit) ) components, FPGA (Field-programmable Gate Arrays) components, CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components; in addition, any method steps and/or devices, units or means likely to be implemented as software components may for example be based on any security architecture capable e.g. of authentication, authorization, keying and/or traffic protection;
- devices, apparatuses, units or means can be implemented as individual devices, apparatuses, units or means, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device, apparatus, unit or means is preserved,
- an apparatus may be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of an apparatus or module, instead of being hardware implemented, be implemented as software in a (software) module such as a computer program or a computer program product comprising executable software code portions for execution/being run on a processor;
- a device may be regarded as an apparatus or as an assembly of more than one apparatus, whether functionally in cooperation with each other or functionally independently of each other but in a same device housing, for example.
The present invention also covers any conceivable combination of method steps and operations described above, and any conceivable combination of nodes, apparatuses, modules or elements described above, as long as the above-described concepts of methodology and structural arrangement are applicable.
There is provided session initiation for device-to-device communication using a local address format, which exemplarily comprises detecting an address of a destination device for device-to-device communication to be of a local address format, creating a session initiation request for device-to-device communication using the detected local address format of the destination device, and sending the created session initiation request on a control plane to a local serving network node.
According to specific and non-limiting examples, features thereof may comprise at least one of:
- at the MME: a SIP handler and/or the issuing of a D2D Bearer setup request to the eNodeB,
- at the eNodeB: optional detection of NAS message with a new session protocol identifier and delivery of NAS message from the source UE to the MME encapsulated in the Sl application protocol or from the MME to the destination UE encapsulated in the RRC message. As an option, the eNodeB could detect a D2D call directly by detecting a new local NAI format in the session initiation protocol.
- at the UE: the application software which determines, when and to which calls to use the D2D format and how to create the D2D format, a switch point (e.g. implemented in software) to treat regular connections differently from D2D connections, and/or sending of NAI. D2D format messages via NAS messages in the control plane .
Even though the invention is described above with reference to the examples according to the accompanying drawings, it is to be understood that the invention is not restricted thereto. Rather, it is apparent to those skilled in the art that the present invention can be modified in many ways without departing from the scope of the inventive idea as disclosed herein.

Claims

Claims
1. A method comprising creating an address of a destination device for device-to-device communication to be of a local address format, creating a session initiation request for device-to- device communication using the created local address format of the destination device, and sending the created session initiation request on a control plane to a local serving network node.
2. The method according to claim 1, comprising sending the created session initiation request using a control plane message to a local network node.
3. The method according to claim 1 or 2, wherein the session initiation request comprises a session initiation protocol invitation message.
4. The method according to claim 2 or 3, wherein the control plane message comprises a non-access stratum message .
5. The method according to any one of claims 1 to 4, comprising adding a session initiation protocol identifier.
6. The method according to any one of claims 1 to 5, the local address format indicating that the devices for device-to-device communication are located in a common subnet area of a communication network.
7. The method according to any one of claims 1 to 6, wherein the local address format is a predetermined format of at least one of a network address identifier, an Internet address, an Intranet address, a phone number, a uniform resource identifier, and a uniform resource locator .
8. The method according to any one of claims 1 to 7, comprising establishing a local device-to-device bearer to the destination device upon request from the local network node.
9. The method according to any one of claims 1 to 8, wherein the local network node is at least one of a network access node such as a base station and a mobility management entity.
10. The method according to any one of claims 1 to 9, wherein the method is operable at a source device for device-to-device communication.
11. A method comprising receiving a control plane message including a session initiation request for device-to-device communication from a local network node, identifying, in the received control plane message, a session initiation protocol identifier, and processing the session initiation request for initiating device-to-device communication with a source device .
12. The method according to claim 11, the processing further comprising passing the session initiation request to an application layer for handling device-to-device session initiation.
13. The method according to claim 11 or 12, comprising establishing a local device-to-device bearer to the source device upon request from the local network node.
14. The method according to any one of claims 11 to 13, wherein the session initiation request comprises a session initiation invitation message.
15. The method according to any one of claims 11 to 14, wherein the control plane message comprises a non-access stratum message.
16. The method according to any one of claims 11 to 15, wherein the method is operable at a destination device for device-to-device communication.
17. A method comprising receiving a control plane message including a session initiation request for device-to-device communication, detecting, in the received control plane message, a session initiation protocol identifier, and forwarding the control plane message including the session initiation request for device-to-device communication for another network node.
18. The method according to claim 17, wherein when the control plane message is received from a device, the control plane message is forwarded to a local network node, and when the control plane message is received from a local network node, the control plane message is forwarded to a device.
19. The method according to claim 17 or 18, wherein the control plane message comprises a non-access stratum message .
20. The method according to any one of claims 17 to 19, comprising setting up a device-to-device bearer between devices for device-to-device communication upon receipt of a device-to-device bearer set-up request from a local network node.
21. The method according to any one of claims 18 to 20, wherein the local network node is a mobility management entity, and wherein the device is one of a source device and a destination device for device-to-device communication .
22. The method according to any one of claims 17 to 21, wherein the method is operable at a network access node such as a base station.
23. A method comprising receiving a session initiation request on a control plane from a device, detecting, in the received session initiation request, an address of a destination device for device- to-device communication to be of a local address format, resolving the local address format for locating the destination device and searching for the destination device, and delivering a session initiation request for device- to-device communication using the detected local address format of the destination device on a control plane to the destination device.
24. The method according to claim 23, comprising forwarding the created session initiation request using a control plane message to a local network node.
25. The method according to claim 23 or 24, wherein the session initiation request comprises a session initiation invitation message.
26. The method according to claim 23 or 24, wherein the control plane message comprises a non-access stratum message .
27. The method according to any one of claims 23 to 26, comprising identifying the received session initiation request as a session initiation invitation message by means of a session initiation protocol identifier.
28. The method according to any one of claims 23 to 27, comprising issuing a device-to-device bearer set-up request to a local network node.
29. The method according to any one of claims 23 to 28, wherein the local address format is a predetermined format of at least one of a network address identifier, an Internet address, an Intranet address, a phone number, a uniform resource identifier, and a uniform resource locator .
30. The method according to any one of claims 23 to 29, wherein the local network node is a network access node such as a base station, and wherein the device is one of a source device and a destination device for device-to- device communication.
31. The method according to any one of claims 23 to 30, wherein the method is operable at a mobility management entity.
32. An apparatus comprising a creator configured to create an address of a destination device for device-to-device communication to be of a local address format, a creator configured to create a session initiation request for device-to-device communication using the created local address format of the destination device, and a transmitter configured to send the created session initiation request on a control plane to a local serving network node.
33. The apparatus according to claim 32, wherein the transmitter is further configured to send the created session initiation request using a control plane message to a local network node.
34. The apparatus according to claim 32 or 33, wherein the session initiation request comprises a session initiation protocol invitation message.
35. The apparatus according to claim 33 or 34, wherein the control plane message comprises a non-access stratum message .
36. The apparatus according to any one of claims 32 to 35, comprising an adder configured to add a session initiation protocol identifier.
37. The apparatus according to any one of claims 32 to
36, the local address format indicating that the devices for device-to-device communication are located in a common subnet area of a communication network.
38. The apparatus according to any one of claims 32 to
37, wherein the local address format is a predetermined format of at least one of a network address identifier, an Internet address, an Intranet address, a phone number, a uniform resource identifier, and a uniform resource locator .
39. The apparatus according to any one of claims 32 to
38, comprising an establisher configured to establish a local device-to-device bearer to the destination device upon request from the local network node.
40. The apparatus according to any one of claims 32 to 39, wherein the local network node is at least one of a network access node such as a base station and a mobility management entity.
41. The apparatus according to any one of claims 32 to 40, wherein the apparatus comprises a source device for device-to-device communication.
42. An apparatus comprising a receiver configured to receive a control plane message including a session initiation request for device-to-device communication from a local network node, an identifier configured to identify, in the received control plane message, a session initiation protocol identifier, and a session processor configured to process the session initiation request for initiating device-to- device communication with a source device.
43. The apparatus according to claim 42, the session processor being further configured to pass the session initiation request to an application layer for handling device-to-device session initiation .
44. The apparatus according to claim 42 or 43, comprising an establisher configured to establish a local device-to-device bearer to the source device upon request from the local network node.
45. The apparatus according to any one of claims 42 to
44, wherein the session initiation request comprises a session initiation invitation message.
46. The apparatus according to any one of claims 42 to
45, wherein the control plane message comprises a non- access stratum message.
47. The apparatus according to any one of claims 42 to 46, wherein the apparatus comprises a destination device for device-to-device communication.
48. An apparatus comprising a receiver configured to receive a control plane message including a session initiation request for device-to-device communication, a detector configured to detect, in the received control plane message, a session initiation protocol identifier, and a transmitter configured to forward the control plane message including the session initiation request for device-to-device communication for another network node .
49. The apparatus according to claim 48, wherein when the control plane message is received from a device, the transmitter is configured to forward the control plane message to a local network node, and when the control plane message is received from a local network node, the transmitter is configured to forward the control plane message to a device.
50. The apparatus according to claim 48 or 49, wherein the control plane message comprises a non-access stratum message.
51. The apparatus according to any one of claims 48 to 50, comprising a processor configured to set up a device-to-device bearer between devices for device-to-device communication upon receipt of a device-to-device bearer set-up request from a local network node.
52. The apparatus according to any one of claims 49 to 51, wherein the local network node is a mobility management entity, and wherein the device is one of a source device and a destination device for device-to- device communication.
53. The apparatus according to any one of claims 48 to
52, wherein the apparatus comprises a network access node such as a base station.
54. An apparatus comprising a receiver configured to receive a session initiation request on a control plane from a device, a detector configured to detect, in the received session initiation request, an address of a destination device for device-to-device communication to be of a local address format, a resolver configured to resolve the local address format for locating the destination device and to search for the destination device, and a transmitter configured to deliver a session initiation request for device-tp-device communication using the detected local address format of the destination device on a control plane to the destination device .
55. The apparatus according to claim 54, wherein the transmitter is further configured to send the created session initiation request using a control plane message to a local network node.
56. The apparatus according to claim 54 or 55, wherein the session initiation request comprises a session initiation invitation message.
57. The apparatus according to claim 55 or 56, wherein the control plane message comprises a non-access stratum message .
58. The apparatus according to any one of claims 54 to 57, comprising an identifier configured to identify the received session initiation request as a session initiation invitation message by means of a session initiation protocol identifier.
59. The apparatus according to any one of claims 54 to
58, comprising an issuer configured to issue a device-to-device bearer set-up request to a local network node.
60. The apparatus according to any one of claims 54 to
59, wherein the local address format is a predetermined format of at least one of a network address identifier, an Internet address, an Intranet address, a phone number, a uniform resource identifier, and a uniform resource locator .
61. The apparatus according to any one of claims 54 to
60, wherein the local network node is a network access node such as a base station, and wherein the device is one of a source device and a destination device for device-to-device communication.
62. The apparatus according to any one of claims 54 to 61, wherein the apparatus comprises a mobility management entity.
63. A computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to any one of claims 1 to 10.
64. A computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to any one of claims 11 to 16.
65. A computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to any one of claims 17 to 22.
66. A computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to any one of claims 23 to 31.
EP08804099A 2008-09-12 2008-09-12 Session initiation for device-to-device communication Withdrawn EP2324616A1 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2008/062134 WO2010028690A1 (en) 2008-09-12 2008-09-12 Session initiation for device-to-device communication

Publications (1)

Publication Number Publication Date
EP2324616A1 true EP2324616A1 (en) 2011-05-25

Family

ID=40551371

Family Applications (1)

Application Number Title Priority Date Filing Date
EP08804099A Withdrawn EP2324616A1 (en) 2008-09-12 2008-09-12 Session initiation for device-to-device communication

Country Status (2)

Country Link
EP (1) EP2324616A1 (en)
WO (1) WO2010028690A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014011114A1 (en) 2014-07-26 2016-01-28 On Point Indicators Gmbh Activation device for activating temperature indicators for the identification of blood bags
CN108496406A (en) * 2016-03-24 2018-09-04 摩托罗拉移动有限责任公司 Method and apparatus for establishing peer to peer connection in the mobile communication network

Families Citing this family (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101296021B1 (en) 2008-10-29 2013-08-12 노키아 코포레이션 Apparatus and method for dynamic communication resource allocation for device-to-device communications in a wireless communication system
US9320067B2 (en) 2008-11-24 2016-04-19 Qualcomm Incorporated Configuration of user equipment for peer-to-peer communication
US8761099B2 (en) 2009-01-16 2014-06-24 Nokia Corporation Apparatus and method of scheduling resources for device-to-device communications
US8588803B2 (en) * 2010-06-18 2013-11-19 Nokia Corporation Method and apparatus for resource scheduling for network controlled D2D communications
CN101902826B (en) * 2010-06-30 2013-09-25 北京乔讯科技有限公司 Method and system for establishing data connection
CN103181138B (en) * 2010-11-12 2016-08-03 诺基亚技术有限公司 Method and apparatus for the communication of device-to-device
US9826404B2 (en) * 2011-01-11 2017-11-21 Qualcomm Incorporated System and method for peer-to-peer authorization via non-access stratum procedures
US8965415B2 (en) * 2011-07-15 2015-02-24 Qualcomm Incorporated Short packet data service
CN103002578B (en) * 2011-09-08 2016-06-22 中国移动通信集团公司 Realize the method for D2D data transmission, Apparatus and system in cellular networks
US9521644B2 (en) * 2012-01-31 2016-12-13 Qualcomm Incorporated Methods and apparatus for providing network-assisted end-to-end paging between LTE devices
US8660078B2 (en) 2012-02-07 2014-02-25 Qualcomm Incorporated Data radio bearer (DRB) enhancements for small data transmissions apparatus, systems, and methods
GB2500720A (en) * 2012-03-30 2013-10-02 Nec Corp Providing security information to establish secure communications over a device-to-device (D2D) communication link
US9560686B2 (en) 2012-04-27 2017-01-31 Lg Electronics Inc. Method and apparatus for reconfiguring device-to-device connection information in wireless communication system
EP2859771A2 (en) * 2012-05-10 2015-04-15 Interdigital Patent Holdings, Inc. System level procedures and methods to enable data sharing in cellular network
US9798457B2 (en) 2012-06-01 2017-10-24 Microsoft Technology Licensing, Llc Synchronization of media interactions using context
US9381427B2 (en) 2012-06-01 2016-07-05 Microsoft Technology Licensing, Llc Generic companion-messaging between media platforms
WO2013183727A1 (en) 2012-06-06 2013-12-12 京セラ株式会社 Communication control method, user terminal, processor, storage medium, and base station
US8913518B2 (en) 2012-08-03 2014-12-16 Intel Corporation Enhanced node B, user equipment and methods for discontinuous reception in inter-ENB carrier aggregation
WO2014022797A1 (en) 2012-08-03 2014-02-06 Intel Corporation Device trigger recall/replace feature for 3gpp/m2m systems
US9036603B2 (en) 2012-08-03 2015-05-19 Intel Corporation Network assistance for device-to-device discovery
US9363702B2 (en) 2012-08-03 2016-06-07 Intel Corporation Method and system for enabling device-to-device communication
US9191828B2 (en) 2012-08-03 2015-11-17 Intel Corporation High efficiency distributed device-to-device (D2D) channel access
US9526022B2 (en) 2012-08-03 2016-12-20 Intel Corporation Establishing operating system and application-based routing policies in multi-mode user equipment
CN103686676A (en) 2012-08-31 2014-03-26 中兴通讯股份有限公司 Communication method and device of device-to-device communication system and system
GB2506118B (en) 2012-09-19 2015-06-03 Broadcom Corp Apparatus and method for communication
EP2723143A1 (en) * 2012-10-19 2014-04-23 NEC Corporation Enhanced RRC signaling messages
CN104885552A (en) * 2012-11-06 2015-09-02 诺基亚技术有限公司 Method and apparatus for device-to-device communication
KR101830039B1 (en) 2012-11-28 2018-02-19 후지쯔 가부시끼가이샤 Method and apparatus for configuring information, reporting connection setup request and system
CN104823517B (en) 2012-11-29 2019-04-23 Lg电子株式会社 Method and device for the communication being arranged in the direct-connected service system of WI-FI
KR101944099B1 (en) * 2012-12-06 2019-04-17 한국전자통신연구원 Discovery method and apparatuss for device to device communication in mobile communication system
CN104885553A (en) * 2013-01-17 2015-09-02 富士通株式会社 Information report method for device-to-device communication, user equipment, and base station
CN104105155B (en) * 2013-04-01 2019-07-16 中兴通讯股份有限公司 Receiving device finds the method and user equipment of information, sending device discovery information
KR102021335B1 (en) 2013-04-09 2019-09-16 한국전자통신연구원 Method for advertising service using device-to-device communication and apparatus for performing the method
WO2015021185A1 (en) 2013-08-07 2015-02-12 Interdigital Patent Holdings, Inc. Distributed scheduling for device-to-device communication
EP3061298A4 (en) 2013-10-23 2017-05-24 Telefonaktiebolaget LM Ericsson (publ) A network node and method for handling cellular and d2d communications in a wireless communications network
US10172044B2 (en) 2016-03-24 2019-01-01 Motorola Mobility Llc Method and device for data communication over a peer-to-peer connection in a mobile communication network

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1527623A (en) * 2003-03-07 2004-09-08 �ʼҷ����ֵ��ӹɷ����޹�˾ Method and apparatus for establishing and retaining point-to-point communication radio chaining in radio communication network
GB0607294D0 (en) * 2006-04-11 2006-05-24 Nokia Corp A node

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2010028690A1 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014011114A1 (en) 2014-07-26 2016-01-28 On Point Indicators Gmbh Activation device for activating temperature indicators for the identification of blood bags
CN108496406A (en) * 2016-03-24 2018-09-04 摩托罗拉移动有限责任公司 Method and apparatus for establishing peer to peer connection in the mobile communication network
CN108496406B (en) * 2016-03-24 2022-10-28 摩托罗拉移动有限责任公司 Method and apparatus for establishing peer-to-peer connection in mobile communication network

Also Published As

Publication number Publication date
WO2010028690A1 (en) 2010-03-18

Similar Documents

Publication Publication Date Title
EP2324616A1 (en) Session initiation for device-to-device communication
US20220124147A1 (en) Application relocation method and apparatus
JP6483617B2 (en) Terminal device, relay terminal device, and communication control method
EP2753133B1 (en) Method of handling proximity service in wireless communication system
US9686635B2 (en) System level procedures and methods to enable data sharing in cellular network
CN108029017B (en) Method for secure wifi call connection through managed public WLAN access
US7974269B2 (en) Mobile communication control method and mobile communication system
US9277522B2 (en) Exchanging rich communication suite capability information in a communications system
TWI789081B (en) Method of routing an emergency call, non-transitory computer readable medium, and mobility management entity
US8914869B2 (en) Gateway system and method for implementing access to various media
EP2782372B1 (en) Method, network element and ue achieving identifier and location separation and interface identifier allocation
US11902389B2 (en) Mechanism to facilitate signaling traffic
US9877346B2 (en) Method and nodes for handling ESM information
KR20140129229A (en) Internet protocol connectivity over a service-oriented architecture bus
CN106470465B (en) WIFI voice service initiating method, LTE communication equipment, terminal and communication system
EP2865154B1 (en) Network assisted proximity service session management
US10021512B2 (en) Switching to advertising locator after connection establishment
JP2016515780A (en) Neighbor communication service realization method and apparatus
EP3409002B1 (en) Method and device for data communication over a peer-to-peer connection in a mobile communication network
CN107211008B (en) Supporting dual registration of user equipment to an IP multimedia subsystem
US20230052569A1 (en) Method and nodes for handling connectivity to a data network
WO2015171023A1 (en) Establishing a multipath tcp (mptcp) connection
CN118413834A (en) Apparatus, method and computer program
CN108235428B (en) Method for realizing registration of UE (user equipment) with P-CSCF (proxy Call Session control function), MME (mobility management entity) equipment and PGW (packet gateway) equipment
US10873561B2 (en) Method and apparatus for allocating IP parameter

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20110216

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: AL BA MK RS

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20120403