WO2019068223A1

WO2019068223A1 - Group configuration and management in device-to-device communications

Info

Publication number: WO2019068223A1
Application number: PCT/CN2017/105272
Authority: WO
Inventors: Zhi Wang; Yigang Cai
Original assignee: Nokia Technologies Oy
Priority date: 2017-10-06
Filing date: 2017-10-06
Publication date: 2019-04-11

Abstract

According to an aspect, a method for configuring device-to-device communication is provided. In said method, a network node receives a request for a link-level group identifier to be used in device-to-device communication. The request comprises at least a terminal device identifier identifying the requesting terminal device and information on a communication application. The network node determines using the terminal device identifier, based on device-to-device permission information, whether the requesting terminal device has a permission for the link-level group identifier. In response to the requesting terminal device having the permission, if the information on the communication application comprises an application-level group identifier identifying a group associated with the communication application, the network node retrieves using the application-level group identifier, the link-level group identifier from mappings between application-level and link-level group identifiers, and causes sending to the requesting terminal device a response comprising the link-level group identifier.

Description

GROUP CONFIGURATION AND MANAGEMENT IN DEVICE-TO-DEVICE COMMUNICATIONS

FIELD OF THE INVENTION

The exemplary and non-limiting embodiments of this invention relate generally to wireless communications networks， and more particularly to device-to-device group communication.

BACKGROUND ART

The following description of background art may include insights， discoveries， understandings or disclosures， or associations together with dis-closures not known to the relevant art prior to the present invention but provided by the invention. Some such contributions of the invention may be specifically pointed out below， whereas other such contributions of the invention will be apparent from their context.

In traditional communication in a cellular network， all communication between mobile devices occurs via one or more base stations. In contrast， device-to-device (D2D) communication provides an option for direct communication between two mobile devices without traversing the base station (BS) or core network. Device-to-Device (D2D) communication has been widely recognized as an efficient way for improving system performance (for example， spectral efficiency， throughput， energy efficiency， delay and/or fairness) for future wireless networks. For example， 3GPP that is a standardisation body for future wireless networks， has defined a device-to-device (D2D) Proximity-based Service (ProSe) architecture. That includes a proposal for one-to-many D2D communication， i.e.， for D2D group communication. The proposal requires that a specific group identifier is used for triggering group communication for a specific group of mobile devices， but is silent on how to provide the mobile devices with the specific group identifier.

SUMMARY

The following presents a simplified summary of the invention in order to provide a basic understanding of some aspects of the invention. This summary is not an extensive overview of the invention. It is not intended to identify key/critical elements of the invention or to delineate the scope of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description that is presented later.

Various aspects of the invention comprise methods， apparatuses， a computer program product and a system as defined in the independent claims. Further embodiments of the invention are disclosed in the dependent claims.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following the invention will be described in greater detail by means of exemplary embodiments with reference to the attached drawings， in which

Figure 1 illustrates an example of a communications system；

Figures 2 to 8 illustrate examples of processes；

Figure 9 illustrates an example of a communications system；

Figures 10 to 11 illustrate examples of processes； and

Figures 12 and 13 illustrates an exemplary apparatuses according to embodiments of the invention.

DETAILED DESCRIPTION OF SOME EMBODIMENTS

The following embodiments are exemplary. Although the specification may refer to “an” ， “one” ， or “some” embodiment (s) in several locations， this does not necessarily mean that each such reference is to the same embodiment (s) ， or that the feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments.

Embodiments described may be implemented in any communications system， such as in at least one of the following： Worldwide Interoperability for Microwave Access (WiMAX) ， Global System for Mobile communications (GSM， 2G) ， GSM EDGE radio access Network (GERAN) ， General Packet Radio Service (GRPS) ， Universal Mobile Telecommunications System (UMTS， 3G) based on basic wide-band-code division multiple access (W-CDMA) ， high-speed packet access (HSPA) ， Long Term Evolution (LTE) ， LTE-Advanced， a system based on IEEE 802.11 specifications， a system based on IEEE 802.15 specifications， and/or a fifth generation (5G) mobile or cellular communications system， or beyond.

The embodiments are not， however， restricted to the system given as an example but a person skilled in the art may apply the solution to other communications systems provided with necessary properties. One example of a suitable communications system is the 5G system， as listed above. 5G has been envisaged to use multiple-input-multiple-output (MIMO) multi-antenna transmission techniques， more base stations or nodes than the current network deployments of LTE， by using a so-called small cell concept including macro sites operating in co-operation with smaller local area access nodes and perhaps also employing a variety of radio technologies for better coverage and enhanced data rates. 5G will likely be comprised of more than one radio access technology (RAT) ， each optimized for certain use cases and/or spectrum. 5G system may also incorporate both cellular (3GPP) and non-cellular (for example IEEE) technologies. 5G mobile communications will have a wider range of use cases and related applications including video streaming， augmented reality， different ways of data sharing and various forms of machine type applications， including vehicular safety， different sensors and real-time control. 5G is expected to have multiple radio interfaces， including apart from earlier deployed frequencies below 6 GHz， also higher， that is cmWave and mmWave frequencies， and also being capable of integrating with existing legacy radio access technologies， such as the LTE. Integration with the LTE may be implemented， at least in the early phase， as a system， where macro coverage is provided by the LTE and 5G radio interface access comes from small cells by aggregation to the LTE. In other words， 5G is planned to support both inter-RAT operability (such as LTE-5G) and inter-RI operability (inter-radio interface operability， such as inter-RI operability between cmWave and mmWave) . One of the concepts considered to be used in 5G networks is network slicing in which multiple independent and dedicated virtual sub networks (network instances) may be created within the same infrastructure to run services that have different requirements on latency， reliability， throughput and mobility.

It should be appreciated that future networks will most probably utilize network functions virtualization (NFV) which is a network architecture concept that proposes virtualizing network node functions into “building blocks” or entities that may be operationally connected or linked together to provide services. A virtualized network function (VNF) may comprise， in addition to standard high-volume servers， switches and storage devices， one or more virtual machines running computer program codes using standard or general type servers instead of customized hardware. Cloud computing or cloud data storage may also be utilized. In radio communications， this may mean that node operations are carried out， at least partly， in a server， host or node operationally coupled to a remote radio head. It is also possible that node operations will be distributed among a plurality of servers， nodes or hosts. It should also be understood that the distribution of labor between core network operations and base station operations may differ from that of the LTE or even be non-existent. Some other technology advancements probably to be used are Software-Defined Networking iSDN) ， Big Data， and all-IP， which may change the way networks are being constructed and managed.

Figure 1 illustrates an example of a communications system 100 to which embodiments of the invention may be applied. The communications system comprises two or more user equipment 101， 104 (equivalently called terminal devices) configured for device-to-device (D2D) communication with each other via an interface. Each of the two or more

terminal devices

101， 104 may be configured to one-to-many D2D communication， that is， for group communication. The

terminal devices

101， 104 may be portable or non-portable computing devices which may comprise wireless mobile communication devices operating with or without a subscriber identification module (SIM) in hardware or in software， including， but not limited to， the following types of devices： desktop computer， laptop， touch screen computer， mobile phone， smart-phone， personal digital assistant (PDA) ， handset， e-reading device， tablet， game console， note-book， multimedia device， sensor， actuator， video camera， car， wearable computer， telemetry appliances， and telemonitoring appliances.

Each of the

terminal devices

101， 104 may be connected to at least one radio access network (RAN) 107 via interfaces and the at least one radio access network 107 may be connected to at least one core network 108 via at least one interface.

The device-to-device functionality (one-to-many or one-to-one D2D) in the communications system 100 for the

terminal devices

101， 104 may be achieved in each

terminal device

101， 104 using a

D2D application

103， 106 and a

D2D unit

102， 105. The D2D application (also called later the communication application) is used for defining and managing the groups to which the terminal device or a certain user of the terminal device belongs on application level or layer. Groups to which a terminal device or a user belongs may be defined using application-

level group identifiers

123， 126. The term “application-level” may refer， here and in the following， to application layer as defined in defined in the Internet Protocol Suite also known as TCP/IP (Transmission Control Protocol/Internet Protocol) or in the Open Systems Interconnection (OSI) model or to a corresponding layer in any other present or future conceptual model for communications standardization. The

D2D application

103， 106 may be able to provide connection via an interface to a D2D application server 115. The D2D application server may， for example， maintain application-level user information (e.g.， application-level group identifiers) for the

terminal devices

101， 104 in the communications system 100. The D2D application may be， for example， a social media application (e.g.， Skype^TM， Facebook^TM or WhatsApp^TM) which may provide additional features which take advantage of D2D communication. In this case， a group may simply be a group of contacts within the application or a subset of that group. To give an example of the possible functionalities， a user of the application may be alerted if a person defined as a contact or a friend within the application is nearby.

The

D2D unit

102， 105 may be used for managing higher layer D2D operations (e.g.， link layer or data link layer operations) . For example， the

D2D unit

102， 105 may be configured to discover nearby terminal devices and form D2D links between two or more

terminal devices

101， 104. To enable said operations， the groups to which a terminal device or a user belongs may be defined on link layer as defined in TCP/IP， on data link layer as defined in the OSI model or on any layer corresponding to (data) link layer in any other present or future conceptual model for communications standardization using link-level group identifiers 121， 124. Moreover， the D2D unit may utilize terminal device identifiers 122， 125 identifying the

terminal device

101， 104. The terminal device identifier may also be a link or data link layer identifier. In some embodiments， the link-level group identifier and the terminal device group identifier may be used， respectively， as a destination link layer or data link layer identifier and a source link layer or data link layer identifier in the packets the

terminal device

101， 104 sends to the group defined by link-level group identifier for D2D Communication.

The

terminal devices

101， 104 may also be connected via interfaces to at least one network node comprising a D2D function 109. The D2D function 109 is a logical function that is used for network related actions required for providing D2D communications between the

terminal devices

101， 104 of the network. For example， the D2D function 109 may be used to provision the

terminal devices

101， 104 with necessary parameters for detecting nearby terminal devices and for forming D2D links with said terminal devices and to connect application-level (application-layer) and link-level (link-layer or data link -layer) information， e.g.， via mappings of application-level and link-level identifiers. To achieve said functionalities， the D2D function 109 may be connected via an interface to the D2D application server 115. The D2D function may be further connected to the database server 113 of the network and/or to a service discovery protocol entity 114. The database server 113 may act as a user database supporting network entities that handle calls. It may， for example， contain subscription-related information and/or perform authentication and authorization of the users. On the other hand， the service discovery protocol entity 114 is used to run a service discovery protocol (SDP) which is a network protocol that helps accomplish the automatic detection of

terminal devices

101， 104 and services offered by these devices.

The D2D function 109 may maintain mappings 111 between application-level group identifiers identifying groups in at least one application and link-level group identifiers identifying groups for device-to-device links in a mapping database and device-to-device permission information 110 on

terminal devices

101， 104 in a permission database. The mapping database and the permission database may be local databases. The device-to-device permission information comprises at least information (e.g.， terminal device identifiers) on the

terminal devices

101， 104 that are permitted to engage in D2D communication in the communications system 100. The application-level group identifiers may be provided to the D2D function 109 by the D2D application server 115. In some embodiments， the mappings between the application-level group identifiers and the link-level group identifiers and the device-to-device permission information may be maintained in a single local database. In other embodiments， the mappings and/or the permissions may be maintained in the database server 113 and/or in the D2D application server 115 and/or in some other global database， instead or in addition to the network node implementing the D2D function.

The D2D function may further maintain first attribute information 112 providing D2D-related information on terminal devices and second attribute information providing information on temporary groups which the D2D function has set up. Detailed information on the first and second attribute information are provided in relation to Figures 5 and 6， respectively. The first and second attribute information 112 may be maintained in one or more global databases which may comprise the database server 113 and/or the D2D application server 115 and/or in one or more local databases which may comprise the mapping database and/or the permission database or a combined mapping and permission database.

It should be appreciated that while Figure 1 shows the two

terminal devices

101， 104 connected to a common RAN 107， the terminal devices using D2D communication may also be connected to different RANs. Furthermore， said different RANs may in some cases also be connected to different core networks. In other words， the

terminal devices

101， 104 may be located in different cellular packet data networks. Each cellular packet data network may have its own D2D function 109， D2D application server 115， database server 113 and service discovery protocol 114.

In some embodiments of the invention， the communications system 100 corresponds to a Long Term Evolution (LTE) communications system. In said embodiments， the radio access network 107 may be an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN) ， the database server 113 may be a home subscriber server (HSS) ， the core network 108 may be an Evolved Packet Core (EPC) .

In the embodiments as described in the previous paragraph， the device-to-device communication may be achieved using established D2D proximity services (ProSe) ， sometimes also called proximity-based services. The

D2D applications

103， 106 may be ProSe applications， the D2D application server 115 may be a ProSe application server and the D2D function may be the ProSe function. The service discovery protocol may be the Service Location Protocol (SLP) .

As the name implies， proximity services (ProSe) may be provided when at least two terminal devices are close to each other. ProSe functionalities as defined by 3GPP comprise

·ProSe discovery (EPC-level and direct)

·ProSe direct communication (using E-UTRAN or wireless local area network， WLAN， direct)

Regarding the ProSe discovery， the EPC-level discovery enables detecting that a ProSe-enabled terminal device is in proximity of another ProSe-enabled terminal device， using Evolved UMTS Terrestrial Radio Access (E-UTRA) with or without E-UTRAN or EPC. On the other hand， direct discovery enables similar detection by the terminal device itself by using only the capabilities of the two terminal devices with E-UTRA technology. After the terminal device has detected one or more terminal devices in its proximity， it may utilize ProSe direct communication functionality for providing one-to-many (or one-to-one) communication between the terminal devices by means of user plane transmission using E-UTRA technology via a path not traversing any network node or using WLAN.

In order for the terminal device to utilize one-to-many ProSe direct communication， two different identifiers may be configured： ProSe UE ID acting as a terminal device identifier and a ProSe Layer-2 Group ID acting as a link-level group identifier. The ProSe UE ID is a link layer identifier that is used as a source Layer-2 ID in all the packets the

terminal device

101， 104 sends for one-to-many ProSe direct communication. The ProSe UE ID is configured in the terminal device or self-assigned by the terminal device or if bearer-level security is configured， by the ProSe Key Management Function. ProSe Layer-2 Group ID， on the other hand， identifies the group in the context of one-to-many ProSe Direct Communication. It is used as a destination Layer-2 ID in all the packets the UE sends to this group for one-to-many ProSe Direct Communication. It should be appreciated that in addition to the ProSe UE ID and the ProSe Layer-2 Group ID， other IDs such as application-level identifiers for the terminal device may also defined. For example， a ProSe Application ID and/or an Application Layer Group ID may be defined. The ProSe Application ID is used in the following examples relating ProSe as an application-level group identifier without limiting the examples to use of this particular type of identifier.

In the following， the ProSe is in many instances used as an example of D2D communication without limiting the examples to ProSe. It should be appreciated that implementing the below examples to another D2D communication scheme is a straightforward process for one skilled in the art.

Figure 2 illustrates a process executed by a network node implementing the D2D function 109 in a communications network 100 for enabling D2D communication for a requesting terminal device by configuring a link-level group identifier for the requesting terminal device. The D2D scheme may correspond to ProSe as described above or it may correspond to another present or future D2D communication scheme. The illustrated process as well as all the following illustrated processes relating to the configuration of the link-level group identifier by the network node may be carried out specifically by a separate logic introduced to an existing D2D function. In the case of ProSe， such a logic is called here and in the following ProSe Layer-2 Group ID Provider Logic.

Referring to Figure 2， the network node receives， in block 201， a request for a link-level group identifier to be used in device-to-device communication from a requesting terminal device. The request may comprise at least a terminal device identifier identifying the requesting terminal device and information on a communication application (that is， which application is to be used for providing D2D communication) . If the information on the communication application further comprises an application-level group identifier identifying a group associated with the communication application in block 202， the network node determines， in block 203， using the terminal device identifier， from device-to-device permission information maintained in the system， whether the requesting terminal device has a permission for the link-level group identifier. In response to the requesting terminal device having the permission for the link-level group identifier in block 203， the network node retrieves， in block 204， using the application-level group identifier， the link-level group identifier for the group from mappings， wherein a mapping associates an application-level group identifier with a corresponding link-level group identifier， and causing sending， in block 205， a first response comprising the link-level group identifier to the requesting terminal device. If the information on the communication application does not comprise an application-level group identifier in block 202 and/or if the requesting terminal device is determined not to have permission for the link-level group identifier in block 203， the network node may simply ignore the request. In some embodiments， the network node may， instead of ignoring the message， cause sending an error message to the requesting terminal device.

A corresponding process for requesting a link-level group identifier performed by the requesting terminal device is illustrated in Figure 3.

Referring to Figure 3， the requesting terminal device causes sending， in block 301， a request for a link-level group identifier to be used in device-to-device communication to a network node. Similar to the process of Figure 2， the request may comprise at least a terminal device identifier identifying the requesting terminal device and information on a communication application. Upon receiving the request， the network node may perform， for example， the process of Figure 2. As a result， the requesting terminal device receives， in block 302， a response comprising at least the link-level group identifier from the network node. Finally， the terminal device uses， in block 303， the terminal device identifier and the link-level group identifier for receiving and causing sending data in one-to-many or one-to-one device-to-device communication. For example， the link-level group identifier and the terminal device group identifier may be used， respectively， as destination and source link link-level identifiers in the packets the requesting

terminal device

101， 104 sends to the group defined by link-level group identifier for D2D Communication as described earlier.

The processes as described in relation to Figure 2 and 3 when considering specifically a ProSe function provide a considerable benefit over the state of the art of configuring/authorizing a terminal device for ProSe D2D communication. While ProSe as defined by 3GPP provides processes for pre-configuring and authorizing the terminal device for D2D communication， the existing processes provide the terminal device only with authorization information which does not comprise a ProSe Layer-2 Group ID (link-level group identifier) . As the ProSe Layer-2 Group ID acts as the destination address for triggering group-cast/broadcast for a D2D group， no D2D group may be set up based on prior art processes alone. In other words， said pre-configuration/authorization procedures may only be used for the configuration of receiving terminal devices but not for the configuration of sending (triggering) terminal devices. Therefore， when a sending terminal device wants to trigger group-cast/broadcast to a D2D group that is not configured， there is no existing solution to get the ProSe Layer-2 Group ID necessary for establishing a D2D link.

In the following， further embodiments of the invention are described for an LTE system using ProSe as the D2D scheme. However， it should be appreciated that the aspects of the invention as described in said further embodiments are not limited to LTE or ProSe or any other particular present or future communications system and D2D scheme. Any ProSe-specific terms should be interpreted in a broad manner， that is， to encompass similar terms in other D2D schemes. Moreover， the ProSe Application ID is used in the following embodiments as the application-level (or application-layer) group identifier though it should be appreciated that other identifiers may also be used for identifying the group on higher abstraction layers.

Figure 4 illustrates an alternative process executed by a network node implementing the ProSe function 109 for enabling D2D communication for a requesting terminal device by configuring a ProSe Layer-2 Group ID for the requesting terminal device.

Referring to Figure 4， blocks 401 to 403 correspond to blocks 201 to 203 of Figure 2 when said method is performed by a ProSe function and are therefore not repeated here for brevity. In addition to the determining， in block 403， whether the terminal device has a permission for the ProSe Layer-2 Group ID， the network node determines， in block 404， whether a mapping exists between the ProSe Application ID (or any ProSe Group ID) comprised in the received request and a ProSe Layer-2 Group ID， that is， whether the ProSe Layer-2 Group ID is retrievable from a memory of the ProSe function or from a database. In this embodiment， the network node retrieves， in block 405， the ProSe Layer-2 Group ID only if the requesting terminal device has a permission (block 403) and if the mapping is determined to be available (block 404) . If the requesting terminal device is determined to have the permission (block 403) ， but it is determined that no mapping exists between the ProSe Application ID and the ProSe Layer-2 Group ID (block 404) ， the network node generates， in block 407， a ProSe Layer-2 Group ID for the terminal device. The network node may store the generated ProSe Layer-2 Group ID to a memory of the ProSe function and/or to a database. After the ProSe Layer-2 Group ID has been retrieved or generated， the network node causes sending， in block 406， a response comprising the ProSe Layer-2 Group ID to the terminal device.

Figure 5 is a signalling diagram illustrating the configuration of the ProSe Layer-2 Group ID for the requesting terminal device using the ProSe function 109 for enabling D2D communication.

While many of the steps of the illustrated signalling diagram correspond to steps discussed in detail in relation to Figures 2 and 3 (namely steps 503， 504， 506 and 508 corresponding to steps 301， 201 to 204， 205， 303) ， three features implemented in this embodiment of the invention have not been discussed previously. Firstly， before the requesting terminal device causes sending a request in message 503， the requesting terminal device carries out a pre-configuration procedure with the ProSe function. In the pre-configuration procedure， the ProSe function 105 may provide， upon receiving a pre-configuration request， the requesting terminal device authorization information for a list of public land mobile networks where the requesting terminal device is authorized to perform ProSe Direct Discovery or ProSe Direct Communication or both. In addition， information regarding out-of-coverage operation may be provided. If there is no associated UE context， the ProSe Function may get the subscription information for ProSe Direct Discovery and/or ProSe Direct Communication from the HSS. Upon reception， the requesting terminal device may store， in block 502， the pre-configuration information (that is， authorization information) to a memory.

Secondly， network node implementing the ProSe function generates， in block 505， first attribute information associated with the ProSe Layer-2 Group ID based on prior provisioning of a device-to-device service provided by the network node. The first attribute information may comprise information on a type of permission and/or criteria for using the ProSe Layer-2 Group ID for device-to-device communication. The criteria may relate to one or more following factors： time， location， application type， whether the requesting terminal device is served by a radio access network or not， battery power level of the requesting terminal device and signalling strength level of the requesting terminal device. The generated first attribute information may be comprised in the response when it is sent to the requesting terminal device in message 506.

Thirdly， the requesting terminal device may store， in block 507， any information comprised in the response (i.e.， ProSe Layer-2 Group ID， the generated first attribute information) to a memory of the terminal device.

The embodiments of the invention discussed up to this point describe methods for configuring the link-level group identifier (ProSe Layer-2 Group ID) for a terminal device so that D2D communication with a group defined by an application-level group identifier is enabled. In other words， the group exists on the application level already and only a configuration on the link level is needed. In the following， methods for creating a ProSe group for group-cast/broadcast temporarily (that is， creating an ad-hoc ProSe group) when no group exists even in the application. Creation of such an ad-hoc group may be important or useful in many applications such as in sharing videos/pictures， in certain disaster/safety scenarios and in a backcountry hiking/hunting.

Figure 6 illustrates a process executed by a network node implementing the ProSe function in a communications network for creating a temporary ProSe group and enabling ProSe communication for the requesting terminal device with the temporary ProSe group. The illustrated process as well as the following illustrated processes relating to the creation of temporary groups by the network node may be carried out specifically by a separate logic introduced to the existing ProSe function. Such a logic is here and in the following On-demand ProSe Layer-2 Group ID Generator Logic. In some embodiments， functionalities of the On-demand ProSe Layer-2 Group ID Generator Logic and the ProSe Layer-2 Group ID Provider Logic may be comprised in a single logic.

Referring to Figure 6， the network node receives， in block 601， from a requesting terminal device a request which comprises at least a ProSe UE ID identifying the requesting terminal device and information on a communication application. The request may be a request for setting up a temporary ProSe group. If the information on the communication application comprises a ProSe Application ID identifying a group within the communication application in block 602， the network node may simply ignore the request. The requests comprising the ProSe Application ID may be handled by another process such as the one illustrated in Figure 2， 4 or 5. However， if the information on the communication application comprises no ProSe Application ID in block 602， the network node determines， in block 603， using the ProSe UE ID from device-to-device permission information maintained in the system whether the requesting terminal device has a permission for setting up a temporary group. In response to the requesting terminal device having the permission to set up the temporary group in block 603， the network node generates， in block 604， a temporary ProSe Application ID and， in block 605， a temporary ProSe Layer-2 Group ID based on the temporary ProSe Application ID. Moreover， the network node stores， in block 606， information comprised in the received request and/or the generated IDs. The information comprised in the received request (e.g.， attribute information on the temporary group as will be discussed in the following paragraph) and the generated IDs may be stored， for example， to a local group information database and to a local mapping database， respectively. Finally， the network node causes sending， in block 607， a second response comprising at least the temporary ProSe Application ID and the ProSe Layer-2 Group ID to the requesting terminal device.

In some embodiments illustrated by Figure 6， the request for setting up the temporary group received by the network node may comprise second attribute information relating to the temporary group. The second attribute information may， for example， comprise one or more of following attributes：

·a joining-in attribute defining the temporary group as an open group or a closed group

·one or more attributes relating to security measures

·a timer defining validity of the temporary link-level group identifier in time (and thus life-time of the temporary group) .

If the temporary group is defined as a closed group， the second attribute information may further comprise information on permitted members of the closed group and permission types of each member for accessing the group. For example， some members may only have a read permission for the temporary group while others may have a read/write permission. At least one member of the temporary group may have an administrative permission for managing the temporary group. In some embodiments， a member corresponding to the terminal device which triggered the creation of the temporary group is assigned automatically as an administrator of the group (i.e.， granted an administrative permission for the temporary group) .

The terminal device possessing the administrative permission (that is， acting as the administrator of the temporary group) may be able to， for example， modify any second attribute information relating to the temporary group or release the temporary group. Modifying the second attribute information may comprise， for example， adding/removing members of a closed group， changing to the joining-in attribute and re-defining the timer. In practice， the temporary group management by the administrator is realized by causing sending， by the administrative terminal device， commands to the network node which implements them， communicating with the other terminal devices if necessary. An exemplary process for performing such an administrative action is discussed later in relation to Figure 11 in detail.

The second attribute information may be utilized when a second terminal device requests the temporary ProSe Layer-2 Group ID for the temporary group from the network node. This process is illustrated in Figure 7. It should be appreciated that in some embodiments， the second attribute information may not be utilized in which case the process carried out by the network node may be the same as the one illustrated in Figure 2.

Referring to Figure 7， the

blocks

701 and 702 may be similar to

blocks

201 and 202 of Figure 2 and are thus not repeated here for brevity. The second terminal device may have been provided the ProSe Application ID for the temporary group by the first terminal device (the requesting terminal device) . After the network node has determined that the received request comprises a ProSe Application ID， the network determines， in block 703， based on device-to-device permission information maintained in the system whether the second terminal device has a permission for the ProSe Layer-2 Group ID， similar to block 203 of Figure 2. However， an additional permission check may be performed， in block 704， in the case of temporary groups based on the second attribute information maintained， for example， in the local group information database. Namely， the network node may determine， in block 704， based on the second attribute information whether the temporary group defined by the ProSe Application ID is defined as a closed group and if this is the case， whether the second terminal device or a user of the second terminal device (defined， e.g.， by the ProSe Application ID) is defined as a member of said closed group leading to a positive result for the additional permission check. Obviously， if the temporary group is defined as an open group， said additional check also provides a positive result. If in addition to the “regular” check in block 703， also the check for temporary groups in block 704 provides a positive result， that is， the second terminal device has the permission for the ProSe Layer-2 Group ID and a permission for accessing the temporary group， the network node further determines， in block 705， based on the second attribute information the type of the permission for accessing the temporary group. The type of permission may be， for example， read-only or read/write. In the case of open group， all the terminal devices may have the same permission， e.g.， a read/write permission. Thereafter， the network node retrieves， in block 706， the temporary ProSe Layer-2 Group ID from the mappings based on the temporary ProSe Application ID and causing sending， in block 707， a response comprising at least the temporary ProSe Layer-2 Group ID and information on the type of permission to the second terminal device.

Figure 8 shows a signalling diagram illustrating the processes described already in Figures 6 and 7 as well as the processes performed concurrently by the requesting terminal device (UE₁) and the second terminal device (represented by any of UE₂ to UE_n) .

The process is initiated by the requesting terminal device causing sending， in message 801， a request for setting up a temporary group. Next， the network node (ProSe function) performs， in block 802， steps 601 to 607 of Figure 6.Furthermore， the network node stores， in block 803， the newly generated mapping between the temporary ProSe Application ID and the temporary ProSe Layer-2 Group ID to the mapping database or to some other local database. The network nodes causes sending， in message 804， the response comprising at least the temporary ProSe Application ID and the temporary ProSe Layer-2 Group ID to the requesting terminal device. Upon receiving the response， the requesting terminal device stores， in block 805， the received information to a memory of the terminal device and distributes， in messages 806， the temporary ProSe Application ID for the temporary group to a plurality of (secondary) terminal devices (one or more of UE₂ to UE_n) . In some embodiments， the plurality of terminal devices may correspond to the members of the temporary group defined as a closed group while in other embodiments， the temporary ProSe Application ID may be more widely distributed. Upon receiving the message comprising the ProSe Application ID， each of the plurality of terminal devices may detect in

blocks

807， 808 whether the terminal device should or is able to join the temporary group defined by the ProSe Application ID. As an example of the former case， receiving the temporary ProSe Application ID may cause a user prompt to appear and the detection may be based on a user input resulting from said user prompt. Consequently， the terminal devices which wish to join the temporary group cause sending， in messages 809， requests for the temporary ProSe Layer-2 Group ID for accessing the group on OSI layer 2. While in Figure 8 both of the illustrated secondary terminal devices (UE₂ and UE_n) request the temporary ProSe Layer-2 Group ID， it should be emphasized that not all n terminal devices may cause sending a request based on the detecting. The network node handles the request by performing， in block 810， the steps 701 to 707 of Figure 7. As a result， responses are sent， in messages 811， by the network node to the plurality of terminal device which had sent the requests for the temporary ProSe Layer-2 Group ID. Upon receiving the responses， said terminal devices may store， in

blocks

812， 813， the information comprised in the request (that is， at least the ProSe Layer-2 Group ID and possibly second attribute information pertaining to the temporary group) . After the configuration of a set of terminal devices， comprising at least UE₂ and UE_n， for accessing the temporary group， the requesting terminal device may initiate one or more ProSe-based D2D links between itself and one or more terminal devices in said set of terminal devices.

In some embodiments of the invention， different message types may be used to identify different requests， in addition or instead of the ProSe Application ID (application-level group identifier) -based detection illustrated， for example， in block 202 of Figure 2， block 402 of Figure 4， block 602 of Figure 6 and block 702 of Figure 7. The message type may be an existing parameter in a message. For example， two new message types may be defined in the embodiments of the invention for ProSe communication：

1. Message type “ProSe L2 Group ID Request” for requesting ProSe Layer-2 Group ID.

2. Message type “Temp ProSe L2 Group ID Request” for requesting the building of temporary D2D group.

In some embodiments， further distinctions in the message type may also be made. For example， messages of the type “Temp ProSe L2 Group ID Request” comprising and not comprising second attribute information may have different message types.

D2D group communication plays a critical role in Machine Type Communication (MTC) and Internet of Things (loT) scenarios， specifically in solving the problem caused by massive connection/controlling of MTC/IoT devices. For example， radio network congestion due to massive concurrent data transmission may occur in some MTC applications. One typical application where such problems may occur is bridge monitoring with a large number of sensors. When a train passes through a bridge， all the sensors transmit monitoring data almost simultaneously. The similar phenomenon may happen also in hydrology monitoring during the time of heavy rain and in building monitoring when there is a break-in. The network should be optimized to enable a large number of MTC devices in a particular area to transmit data almost simultaneously. D2D group communication provides a solution to this issue by enabling a group of MTC devices to be controlled by one selective device. All the traffic may be transferred through this device between network and MTC group， and only the traffic that is required by network will be transferred.

Existing D2D group communication technology (i.e.， ProSe Layer-2 Group ID pre-configuration as discussed in relation to messages 501 of Figure 5) is able to solve the problem only partially. For example， in the scenario of smart city or smart building， there would likely be numerous MTC devices such as sensors and smart equipment deployed. Due to the large number of different possible scenarios， it is almost impossible to build a MTC group in advance. For example， the operation of a light controller application for turning on the lights near a user or users may depend on the number of users and their locations. Ideally， the size of the group of lights operating at a given time should be changed dynamically. In some applications， the total number of lights may be very large. These dynamically changing requirements mean that it is impossible to allocate MTC/IoT group in advance. Therefore， only on-demand D2D group communication (D2D group communication with temporary groups) according to the embodiments of the invention may solve the problem.

Figure 9 illustrates an example of a communications system 900 to which some embodiments of the invention may be applied and which enables on-demand D2D group communication for MTC/IoT scenarios. The communications system is for the most part similar to the one illustrated in Figure 1 with elements 901 to 915 and 921 to 926 corresponding to elements 101 to 115 and 121 to 126 of Figure 1. However， one new element 930 corresponding to a machine type communication (MTC) server is included in the system of Figure 9. The MTC server may correspond， for example， to an MTC-IWF (Machine Type Communication InterWorking Function) server as defined by 3GPP with added D2D functionalities implemented using a new D2D Group Management logic. The MTC server may be connected to the database server 913. Moreover， the MTC server is connected to the RAN 907 directly or via gateway nodes and/or other core network nodes. In other embodiments， other connections to other network elements may be also be provided.

The MTC server may have three different functionalities relating to the creation and management of temporary groups. All of said functionalities involve communication with a terminal device having administrative permission for the temporary group. First of said functionalities is demonstrated by Figure 10 which illustrates a signalling diagram for setting up a temporary group， similar to Figure 8.

In Figure 10， the process of setting up (or creating) a temporary group is not initiated by the terminal device but by the MTC server. The MTC server may receive， in block 1001， input from MTC application layer， for example， a group member ID list and a group administrator ID defining the members of the temporary group and the administrative member of the temporary group， respectively. Based on the received information， the MTC server generates， in block 1001， a new device trigger (e.g.， “Temp D2D Group Build” ) and causes sending， in message 1002， it to the terminal device acting as the administrator for the temporary group to be created (the terminal device being identified by MTC application layer) . In response to receiving the trigger requesting creation of a temporary group， the terminal device causes sending， in message 1003， a request for the ProSe Layer Group ID (or other link-level group identifier) to the network node implementing the D2D function. The steps 1004 to 1016 correspond to the steps 802 to 814 of Figure 8 and are therefore not repeated here. In some embodiments， the terminal device acting as the administrator may cause sending an acknowledgment to the MTC server after the temporary group has been created (that is， after step 1006 and/or step 1014/1015) .

The second and third functionalities of the MTC server relate to the management of the existing temporary group. In short， the MTC server may request the administrative terminal device to perform any administrative actions available to it. The MTC server may request from the administrative terminal device the addition or removal of members of the temporary group based on commands from MTC application layer. Moreover， the MTC server may request from the administrative terminal device the release of the temporary group based on commands from MTC application layer. Other commands or data may also be delivered from the MTC server to the terminal devices via the administrative terminal device， for example， a command requesting the change of the temporary group from an open group to a closed group or vice versa.

Figure 11 illustrates an exemplary process for modifying one of the properties of the temporary group as defined in the second attribute information. Similar to Figure 10， the MTC server may receive， in block 1101， input from MTC application layer. The input may comprise a command to change one or more of the second attribute information properties of the temporary group. In this example， the command concerns a particular terminal device (UE₂) . The command may define， for example， that the particular terminal device UE₂ is to be added or removed from the temporary group or that its permission should be changed from read/write to read-only. Based on the received information， the MTC server generates， in block 1001， a new device trigger and causes sending， in message 1102， the trigger to the administrative terminal device. In response to receiving the trigger， the terminal device causes sending， in message 1103， a request for changing said property of the temporary group to the network node. Upon receiving the request， the network node detects， in block 1104， what the type of the request is. Depending on the type of the request， the network node stores or removes， in block 1105， information due to the change in the temporary group to or from a local/global database. Then， the network node causes sending， in message 1106， information on the change to the terminal device UE₂ affected by the change. Upon receiving the information on the change， the terminal device UE₂ performs， in block 1107， the actions requested of it in the request for implementing the change. These actions may comprise releasing any current D2D links， storing a ProSe Layer-2 Group ID for enabling D2D communication with the temporary group or removing an existing ProSe Layer-2 Group ID for disabling D2D communication with the temporary group or storing a new permission definition. After the actions are completed， the terminal device causes sending， in message 1108， an acknowledgment to the network node. In response to receiving the acknowledgment， the network node causes sending， in message 1109， a response to the administrative terminal device. The administrative terminal device may store， in block 1110， any information comprised in the request to a memory and cause sending， in message 1111， an acknowledgment to the MTC server.

In some embodiments， the network node may fulfil the request for changing one or more second attribute information properties from the administrative terminal device without communicating with the terminal devices affected by the request， that is， steps 1106 to 1108 may in some cases be omitted.

In the embodiments where a release of the temporary group is requested by the MTC server， the process may be similar to the one illustrated in Figure 11 with the distinction that network node may need to communicate with all the terminal device in the temporary group in order to implement the release.

It should be appreciated that in some embodiments the administrative terminal device may perform any of the functionalities relating to management of the temporary group described in relation to Figure 11 by itself without a command from a MTC server (even in a system according to Figure 1 where no MTC server exists) . In such embodiments， the process of Figure 11 with the first two

steps

1101， 1102 excluded may be performed.

The blocks， related functions， and information exchanges described above by means of Figures 2 to 8， 10 and 11 are in no absolute chronological order， and some of them may be performed simultaneously or in an order differing from the given one.

Figure 12 illustrates an exemplary apparatus 1201 configured to carry out the functions described above in connection with the network node implementing a D2D function (e.g.， a ProSe Function) . The apparatus may be an electronic device comprising electronic circuitries. The apparatus may be a separate network entity or a plurality of separate entities. The apparatus may comprise a communication control circuitry 1210 such as at least one processor， and at least one memory 1230 including a computer program code (software) 1231 wherein the at least one memory and the computer program code (software) are configured， with the at least one processor， to cause the apparatus to carry out any one of the embodiments of the network node described above.

The memory 1230 may be implemented using any suitable data storage technology， such as semiconductor based memory devices， flash memory， magnetic memory devices and systems， optical memory devices and systems， fixed memory and removable memory. The memory may comprise one or more databases 1232 which may comprise permission information， information on mappings， first attribute information and/or second attribute information as described in previous embodiments. The memory 1230 may be connected to the communication control circuitry 1220 via an interface.

The apparatus may further comprise a communication interface (Tx/Rx) 1210 comprising hardware and/or software for realizing communication connectivity according to one or more communication protocols. The communication interface may provide the apparatus with communication capabilities to communicate in the cellular communication system and enable communication with network nodes (e.g.， with the database server 113， D2D application server 115 and/or the network node 114 implementing a service discovery protocol as illustrated in Figure 1) and with terminal devices (e.g.， with terminal devices 101， 104) . The communication interface 1210 may comprise standard well-known components such as an amplifier， filter， frequency-converter， (de) modulator， and encoder/decoder circuitries and one or more antennas.

Referring to Figure 12， the communication control circuitry 1220 may comprise D2D circuitry 1221 configured to perform D2D functions according to an established D2D scheme (for example， implementing a ProSe function as defined by 3GPP) . The communication control circuitry 1220 further comprises a D2D configuration circuitry 1222 configured to configure any requesting terminal device for initiating D2D communication by providing a link-level group identifier (e.g.， ProSe Layer-2 Group ID in ProSe) . The D2D configuration circuitry 1222 may correspond to a hardware realization of ProSe Layer-2 Group ID Provider Logic. The D2D configuration circuitry 1222 may be， for example， configured to carry out one or more of the following steps： steps of Figures 2 and 4 and steps 504 to 506 of Figure 5. The communication control circuity 1220 also comprises a D2D temporary group generation circuitry 1223 configured to generate a new temporary group for D2D communication upon a request by a terminal device. The D2D temporary group generation circuitry 1223 may correspond to a hardware realization of On-demand ProSe Layer-2 Group ID Generator Logic. The D2D temporary group generation circuitry 1223 may be， for example， configured to carry out one or more of the following steps： the steps of Figure 6， steps 802 to 804 of Figure 8， steps 1004 to 1006， 1012 and 1013 of Figure 10 and steps 1104 to 1106 of Figure 11. Either of the D2D configuration circuitry 1222 and the D2D temporary group generation circuitry 1223 may be configured to perform the process of Figure 7. In some embodiments， the D2D configuration circuitry 1222 and the D2D temporary group generation circuitry 1223 may be comprised in a single circuitry.

Figure 13 illustrates an exemplary apparatus 1301 configured to carry out the functions described above in connection with the

terminal devices

101， 104 supporting D2D communication. The apparatus may be an electronic device comprising electronic circuitries. The apparatus may be a separate network entity or a plurality of separate entities. The apparatus may comprise a communication control circuitry 1310 such as at least one processor， and at least one memory 1330 including a computer program code (software) 1331 wherein the at least one memory and the computer program code (software) are configured， with the at least one processor， to cause the apparatus to carry out any one of the embodiments of the terminal device (requesting terminal device or second terminal device) described above.

The memory 1330 may be implemented using any suitable data storage technology， such as semiconductor based memory devices， flash memory， magnetic memory devices and systems， optical memory devices and systems， fixed memory and removable memory. The memory may comprise a database 1332 which may comprise at least one or more application-level group identifiers， one or more link-level group identifiers and/or permission information (e.g.， concerning closed group memberships) . The memory 1330 may be connected to the communication control circuitry 1320 via an interface.

The apparatus may further comprise a communication interface (Tx/Rx) 1310 comprising hardware and/or software for realizing communication connectivity according to one or more communication protocols. The communication interface may provide the apparatus with communication capabilities to communicate in the communication system and enable communication with network nodes and terminal devices (using D2D communication) ， for example. The communication interface 1310 may comprise standard well-known components such as an amplifier， filter， frequency-converter， (de) modulator， and encoder/decoder circuitries and one or more antennas.

Referring to Figure 13， the communication control circuitry 1320 may comprise a D2D circuitry 1321 configured to enable D2D communication between the apparatus and terminal devices in a D2D group. The communication control circuitry 1320 further comprises an enhanced D2D circuitry 1322 configured to configure the apparatus for initiating (triggering) D2D communication by requesting the network node implementing the D2D function for setting up a temporary group for D2D communication and further configured to distribute information on said temporary groups. The enhanced D2D circuitry 1322 may be， for example， configured to carry out one or more of the following steps： steps of Figure 3，

steps

502， 503 and 507 of Figure 5，

steps

801， 805 to 809 and 811 to 813 of Figure 8，

steps

1003， 1007 to 1011 and 1013 to 1015 of Figure 10 and

steps

1103， 1107， 1108， 1110 and 1111 of Figure 11. Either of the D2D circuitry 1321 and the enhanced D2D circuitry 1322 the may be configured to perform the initiating or triggering the D2D links as shown in， for example， block 508 of Figure 5，block 814 of Figure 8 and block 915 of Figure 9.

Figure 13 may， alternatively， illustrate an exemplary apparatus 1301 configured to carry out the functions described above in connection with the MTC server.

As used in this application， the term ‘circuitry’ refers to all of the following： (a) hardware-only circuit implementations， such as implementations in only analog and/or digital circuitry， and (b) combinations of circuits and software (and/or firmware) ， such as (as applicable) ： (i) a combination of processor (s) or (ii) portions of processor (s) /software including digital signal processor (s) ， software， and memory (ies) that work together to cause an apparatus to perform various functions， and (c) circuits， such as a microprocessor (s) or a portion of a microprocessor (s) ， that require software or firmware for operation， even if the software or firmware is not physically present. This definition of ‘circuitry’ applies to all uses of this term in this application. As a further example， as used in this application， the term ‘circuitry’ would also cover an implementation of merely a processor (or multiple processors) or a portion of a processor and its (or their) accompanying software and/or firmware. The term ‘circuitry’ would also cover， for example and if applicable to the particular element， a baseband integrated circuit or applications processor integrated circuit for a mobile phone or a similar integrated circuit in a server， a cellular network device， or another network device.

In an embodiment， at least some of the processes described in connection with Figures 2 to 8， 10 and 11 may be carried out by an apparatus comprising corresponding means for carrying out at least some of the described processes. Some example means for carrying out the processes may include at least one of the following： detector， processor (including dual-core and multiple-core processors) ， digital signal processor， controller， receiver， transmitter， encoder， decoder， memory， RAM， ROM， software， firmware， display， user interface， display circuitry， user interface circuitry， user interface software， display software， circuit， antenna， antenna circuitry， and circuitry. In an embodiment， the at least one processor， the memory， and the computer program code form processing means or comprises one or more computer program code portions for carrying out one or more operations according to any one of the embodiments of Figures 2 to 8， 10 and 11 or operations thereof.

The techniques and methods described herein may be implemented by various means. For example， these techniques may be implemented in hardware (one or more devices) ， firmware (one or more devices) ， software (one or more modules) ， or combinations thereof. For a hardware implementation， the apparatus (es) of embodiments may be implemented within one or more application-specific integrated circuits (ASICs) ， digital signal processors (DSPs) ， digital signal processing devices (DSPDs) ， programmable logic devices (PLDs) ， field programmable gate arrays (FPGAs) ， processors， controllers， micro-controllers， microprocessors， other electronic units designed to perform the functions described herein， or a combination thereof. For firmware or software， the implementation can be carried out through modules of at least one chipset (procedures， functions， and so on) that perform the functions described herein. The software codes may be stored in a memory unit and executed by processors. The memory unit may be implemented within the processor or externally to the processor. In the latter case， it can be communicatively coupled to the processor via various means， as is known in the art. Additionally， the components of the systems described herein may be rearranged and/or complemented by additional components in order to facilitate the achievements of the various aspects， etc.， described with regard thereto， and they are not limited to the precise configurations set forth in the given figures， as will be appreciated by one skilled in the art.

Embodiments as described may also be carried out in the form of a computer process defined by a computer program or portions thereof. Embodiments of the methods described in connection with Figures 2 to 8， 10 and 11 may be carried out by executing at least one portion of a computer program comprising corresponding instructions. The computer program may be in source code form， object code form， or in some intermediate form， and it may be stored in some sort of carrier， which may be any entity or device capable of carrying the program. For example， the computer program may be stored on a computer program distribution medium readable by a computer or a processor. The computer program medium may be， for example but not limited to， a record medium， computer memory， read-only memory， electrical carrier signal， telecommunications signal， and software distribution package， for example. The computer program medium may be a non-transitory medium. Coding of software for carrying out the embodiments as shown and described is well within the scope of a person of ordinary skill in the art.

Even though the invention has been described above with reference to an example according to the accompanying drawings， it is clear that the invention is not restricted thereto but can be modified in several ways within the scope of the appended claims. Therefore， all words and expressions should be interpreted broadly and they are intended to illustrate， not to restrict， the embodiment. It will be obvious to a person skilled in the art that， as technology advances， the inventive concept can be implemented in various ways. Further， it is clear to a person skilled in the art that the described embodiments may， but are not required to， be combined with other embodiments in various ways.

Claims

A method comprising：

receiving， in a network node， a request for a link-level group identifier to be used in device-to-device communication， wherein the request comprises at least a terminal device identifier identifying the requesting terminal device and information on a communication application；

determining using the terminal device identifier， based on device-to-device permission information， whether the requesting terminal device has a permission for the link-level group identifier； and

in response to the requesting terminal device having the permission for the link-level group identifier， if the information on the communication application comprises an application-level group identifier identifying a group associated with the communication application， retrieving， by the network node， using the application-level group identifier， the link-level group identifier for the group from mappings， wherein a mapping associates an application-level group identifier with a corresponding link-level group identifier， and causing sending， by the network node， to the requesting terminal device a first response comprising the link-level group identifier.
A method according to claim 1， in response to the requesting terminal device having the permission for the link-level group identifier， if the request further comprises the application-level group identifier， the method further comprising：

in response to the application-level group identifier being unretrievable from the mappings， generating， by the network node， the link-level group identifier and causing sending， by the network node， the first response comprising the link-level group identifier to the requesting terminal device.
A method according to claim 1 or 2， in response to the requesting terminal device having the permission for the link-level group identifier， if the request further comprises the application-level group identifier， the method further comprising：

generating， by the network node， first attribute information associated with the link-level group identifier based on prior provisioning of a device-to-device service provided by the network node， wherein the first attribute information comprises information on a type of permission and/or criteria for using the link-level group identifier for device-to-device communication relating to one or more following factors： time， location， application type， whether the requesting terminal device is served by a radio access network or not， battery power level of the requesting terminal device and signalling strength level of the requesting terminal device； and causing sending， by the network node， the first attribute information in the first response to the requesting terminal device.
A method according to any preceding claim， if the request is a request for setting up a temporary group， the method further comprising：

determining， by the network node， based on the terminal device identifier and the device-to-device permission information， whether the requesting terminal device has a permission to set up the temporary group； and

in response to the requesting terminal device having the permission to set up the temporary group， generating， by the network node， a temporary application-level group identifier and a temporary link-level group identifier based on the temporary application-level group identifier and causing sending， by the network node， a second response comprising the temporary application-level group identifier and the temporary link-level group identifier to the requesting terminal device.
A method according to claim 4， further comprising：

receiving in the request for setting up a temporary group second attribute information relating to the temporary group， the second attribute information comprising one or more of following attributes： a joining-in attribute defining the temporary group as an open group or a closed group and if the temporary group is defined as the closed group， further defining members of the closed group， permission types of the members for accessing the group， one or more attributes relating to security measures and a timer defining validity of the temporary link-level group identifier in time； and

in response to the requesting terminal device having the permission to set up the temporary group， storing， by the network node， the second attribute information to a group information database.
A method according to any of claims 4 to 5， further comprising：

storing， by the network node， to the mappings a mapping between the temporary application-level group identifier and the temporary link-level group identifier.
A method according to any of claims 4 to 6， further comprising：

in response to the requesting terminal device having the permission to set up the temporary group， granting， by the network node， the requesting terminal device an administrative permission for the temporary group in the second attribute information；

receiving， in the network node， an administrative request regarding the temporary group from the terminal device， wherein the administrative request relates to updating one or more attributes in the second attribute information or releasing the temporary group； and

carrying out， by the network node， the administrative request with terminal devices in the temporary group.
A method according to claim 1， in response to the requesting terminal device having the permission for the link-level group identifier， if the information on the communication application comprises the application-level group identifier identifying the group within the communication application， the method further comprising：

if the link-level group identifier is a temporary application-level group identifier and the group is a temporary group， determining， by the network node， based on second attribute information maintained in a group information database， whether the temporary group is a closed group or an open group and if the temporary group is a closed group， whether the terminal device has a permission for accessing the temporary group and which type of permission and， in response to the requesting terminal device having the permission for the temporary link-level group identifier and the permission for accessing the temporary group based on the attribute information， retrieving， by the network node， the temporary link-level group identifier from the mappings based on the temporary application-level group identifier and causing sending， by the network node， a third response comprising at least the temporary link-level group identifier and information on the type of permission to the requesting terminal device.
A method comprising：

causing sending， by a requesting terminal device， a request for a link-level group identifier to be used in device-to-device communication to a network node， wherein the request comprises at least a terminal device identifier identifying the requesting terminal device and information on a communication application；

receiving， by the requesting terminal device， a response comprising at least the link-level group identifier from the network node； and

using， by the requesting terminal device， the terminal device identifier and the link-level group identifier for receiving and causing sending data in one-to-many or one-to-one device-to-device communication.
A method according to claim 9， wherein the information on a communication application comprises an application-level group identifier identifying a group within the communication application.
A method according to any of claims 10， further comprising：

before causing sending the request， receiving， by the requesting terminal device， the application-level group identifier defined as a temporary application-level group identifier from a second terminal device.
A method according to claim 9， further comprising：

receiving， by the requesting terminal device， an application-level group identifier identifying a group associated with the communication application in the response from the network node.
A method according to claim 12， if the request is a request for setting up a temporary group， the link-level group identifier being a temporary link-level group identifier and the application-level group identifier being a temporary application-level group identifier， the method further comprising：

causing sending， by the requesting terminal device， in response to receiving the response， the temporary application-level group identifier to one or more terminal devices for joining the temporary group.
A method according to any of claims 13， further comprising：

causing sending， by the requesting terminal device， in the request for setting up the temporary group second attribute information relating to the temporary group， the second attribute information comprising one or more of the following： a joining-in attribute defining the temporary group as an open group or a closed group and if the temporary group is defined as the closed group， further defining members of the closed group， permission types of the members for accessing the temporary group， one or more attributes relating to security measures and a timer defining validity of the temporary link-level group identifier in time.
A method according to claim 14， if the request is the request for setting up the temporary group， the link-level group identifier being the temporary link-level group identifier and the application-level group identifier being the temporary application-level group identifier， the method further comprising：

causing sending， by the requesting terminal device， an administrative request regarding the temporary group to the network node， wherein the administrative request relates to updating one or more attributes in the second attribute information or releasing the temporary group.
A method according to claim 15， wherein causing the sending the request for the link-level group identifier and/or causing the sending the administrative request is performed in response to receiving a message from a server for managing machine type communications.
A method according to any of claims 9 to 16， further comprising：

storing， by the requesting terminal device， information comprised in the response to a memory.
A method according to any of claims 1 to 17， wherein the link-level group identifier is a proximity-based service layer-2 group identifier and the network node is configured to implement a proximity-based service function.
An apparatus comprising：

at least one processor； and

at least one memory comprising a computer program code， wherein the processor， the memory， and the computer program code are configured to cause the apparatus to perform a method according to any of claims 1 to 18.
An apparatus comprising means for carrying out the method ac-cording to any one of claims 1 to 18.
A non-transitory computer readable media having stored thereon instructions that， when executed by a computing device， cause the computing device to to perform a method according to any of claims 1 to 18.
A system comprising at least：

a machine type communication server configured to cause sending commands relating to device-to-device group management；

one or more terminal devices configured to communicate with the machine type communication server and to perform a method according to any of claims 9 to 17 in response to receiving a command from the machine type communication server； and

one or more network nodes configured to enable device-to-device communication for the one or more terminal devices and to perform a method according to any of claims 1 to 8.