Community Core Evolution in Mobile Social Networks

Abstract

Community detection in social networks attracts a lot of attention in the recent years. Existing methods always depict the relationship of two nodes using the temporary connection. However, these temporary connections cannot be fully recognized as the real relationships when the history connections among nodes are considered. For example, a casual visit in Facebook cannot be seen as an establishment of friendship. Hence, our question is the following: how to cluster the real friends in mobile social networks? In this paper, we study the problem of detecting the stable community core in mobile social networks. The cumulative stable contact is proposed to depict the relationship among nodes. The whole process is divided into timestamps. Nodes and their connections can be added or removed at each timestamp, and historical contacts are considered when detecting the community core. Also, community cores can be tracked through the incremental computing, which can help to recognize the evolving of community structure. Empirical studies on real-world social networks demonstrate that our proposed method can effectively detect stable community cores in mobile social networks.

1. Introduction

In the recent years, the way of communication among people has experienced a dramatic change. Thanks to the development of mobile communication technology, the relative geographical topology among passengers can be caught easily. Hence, clustering people in such mobile social networks, which can be further used in information recommendation and other social services, attracts more and more concerns.

There are a lot of literatures concerned with the community detection in social networks, including static approach and dynamic approach. Nodes are usually depicted as people in the real world, and links are always denoted to be the contacts among nodes. The static approach focuses on high aggregation of nodes which have the same features [1, 2]. While the dynamic approach divides the network’s evolving process into lots of timestamps, they not only pay attention to clustering nodes in the network but are also concerned with the computational complexity at each timestamp [3, 4]. At each timestamp, the computational complexity depends on change of links, rather than all links in the network. It is very important when analyzing evolution of the network structure, especially with multiple timestamps. However, few of these methods consider the stability of communities between two timestamps. Intuitively, in our real world, the relationship among people will not change sharply. That is to say, for a giving link𝑙_𝑎,𝑏(𝑡)which denotes a link between nodes𝑎and𝑏at time 𝑡, 𝑙_𝑎,𝑏(𝑡) cannot depict the relationship between nodes𝑎and𝑏exactly. The study in [5] considers the stability in community detection, but it tries to obtain a community partition under the stable modularity, rather than the stable contact.

Moreover, [6] pointed out that intercontact time among people follows the power-law distribution, which means the following: (1) we spend most of our time contacting with the “community” people; (2) there are still a lot of temporary contacts taking place between “strangers.” If all of the links are considered when detecting community, some temporary links among “strangers” will influence the effect. In order to eliminate the negative influence, only familiar links should be concerned. And our question is the following: how to find the real friends having those familiar links with each other in a mobile social network?

The biggest feature of mobile social network is that nodes and links are always changing. The studies in [3, 7] have classified all of the situations that occur at each timestamp into several events, including node add/remove and link (edge) add/remove. And their experiment results demonstrate that discretization of the continuous time is a useful way to model the evolution of the network. In this paper, the discretization of the continuous time is still adopted when modeling the evolution process. However, the prominent difference of our method compared with others is the discrimination between familiar link and temporary link.

Based on previous works [8], the number of familiar links is higher than that of temporary links. In other words, people who come from the same community have higher contact frequency than those who come from different communities. And the changing frequency of familiar link is lower than that of temporary link. That is to say, people who come from the same community always keep the relatively stable contact, while contacts among people who come from different communities seem to be uncertain.

Based on the discussion above, we use “community core” to solve our problem. Unlike our definition, the concept denoted by [5] is based on the nondeterministic community detection algorithm. Generally speaking, a community core in mobile social networks is the subset of a community. For links in the same community core, few changes will occur between consecutive timestamps.

The study in [9] extracts the core structure of social networks using (𝛼,𝛽) community. The authors have discovered the core structure by lots of overlapping (𝛼,𝛽) communities. However, the proposed static heuristic algorithm did not consider the dynamic features of social networks. The study in [5] analyzed the community core in evolving networks. By recursive computation, stable community cores are detected and well tracked. However, the instability of communities in [5] is caused by the instability of the nondeterministic detecting algorithm, which does not suit the community core detection under the instability of links at each timestamp.

In this paper, we propose a novel approach for community core detection in mobile social networks. The main idea of our approach is to find a partition based on stable links in a giving network. To the best of our knowledge, we are the first to find the relatively stable community core using the history cumulative contact in mobile social networks and the first to find the power-law distribution of these contacts’ changing between consecutive timestamps. In order to recognize the change of community core at each timestamp, the tracking mechanism is also concerned.

The rest of this paper is organized as follows. We introduce the preliminaries used in this paper in Section 2. In Section 3, we discuss the characteristics of cumulative stable contact. Then, we present our community core detection and tracking algorithm separately in Section 4. We evaluate our algorithms in Section 5, and we finally conclude the work with Section 6.

2. Preliminary

In this section, we present the notion and the mobile network model that we will use throughout the paper.

Definition 1 (mobile social network). A mobile social network is denoted as𝐺=⟨𝐸,𝑉⟩, where 𝑉 is the vertex set and𝐸⊆𝑉×𝑉is the link set.

The nodes and links of a mobile social network will change according to different timestamps. A mobile social network at𝑇=𝑡is denoted as𝐺(𝑡)=⟨𝐸(𝑡),𝑉(𝑡)⟩. Here,𝑉(𝑡)is the set of nodes that appears at𝑇=𝑡, and𝐸(𝑡)is the set of links that appears at the same timestamp:𝑉(𝑡)⊆𝑉, and𝐸(𝑡)⊆𝐸.

Topologies of a certain mobile social network are always changing due to the time variation, which is the most difference compared with static networks. Like previous works, we treat the continuous time as a sequence of timestamps. Furthermore, nodes and links may be different from the consecutive timestamps. Hence, we use the following four events to describe the evolution of network: node add, node remove, link add, and link remove.

Definition 2 (cumulative stable contact, (CSC)). There is a CSC between two nodes𝑣_𝑖and𝑣_𝑗if and only if their history contact duration is higher than a threshold (we will discuss this threshold in the following section).

As mentioned before, the temporary link cannot depict the relationship between two nodes in the mobile social network. Inversely, two nodes that disconnect at 𝑇=𝑡 cannot demonstrate that they are irrelevant. Considering the history connection among nodes, we use cumulative contact to judge the stability of links.

Definition 3 (community core set). It is denoted as CRS={CO₀,CO₁,…,CO_𝑚}, where CO_𝑖 is a community core and is a subset of 𝐺∶⋃_𝑖=0CO_𝑖(𝑡)⊆𝐺(𝑡).

The community core at 𝑇=𝑡 is a partition about the given network, the same as the concept “community” in previous works. A community set is defined as a partition of a given network: CS={𝐶₀,𝐶₁,…,𝐶_𝑚}. However, we only focus on detecting the “useful links” rather than carry on a cluster process. Hence, some of the nodes and links may not be included in CRS(𝑡) even if they appear at 𝑇=𝑡. Therefore, the biggest difference between community and community core is ⋃_𝑖=0CO_𝑖(𝑡)⊆⋃_𝑗=0𝐶_𝑗(𝑡).

3. Cumulative Stable Link

In this section, we study the characteristics of CSC. First, a well-known mobile social network is introduced. Then, a stable link extraction method is proposed to find the CSC. Finally, we discuss the distribution of the change of CSC (CCSC).

3.1. Dataset

Due to the increasing concern about mobile social networks, various datasets about people’s behavior are collected by researchers. The studies in [8, 10] have collected the traces information about attendants of INFOCOM06 and SIGCOMM09 separately. The features of these datasets are as follows. (1) These datasets include not only the contact information but also the attributes of attendants. The SIGCOMM09 has 76 attendants, and the INFOCOM06 has 78 attendants. (2) Both of these datasets contain several days traces information; more than 300000 timestamps can be used to describe the evolution of networks.

SIGCOMM09 collects the traces information among attendants in SIGCOMM 2009. The dataset not only records the contact time of each device pair but also includes the profile of each attendant such as country, city, institute, and interest. The contact information is recorded in the form of <timestamp, user_id, seen_user_id,…>, which means the scanning time, the scanning device, and the discovered device. Hence, the cumulative contact pair at each timestamp is easier to obtain.

Similar to SIGCOMM09, INFOCOM06 collects the contact traces among attendants in INFOCOM 2006. Each participant was asked to fill in a questionnaire that included name, nationality, affiliation, country, and other items. The contact information is also well refined by the author so that in the form of <user_id, seen_(user_id), start time, end time,…>, which means scanning device, discovered device and their duration contact time.

3.2. Stable Link Extraction

Both the SIGCOMM09 and INFOCOM06 contain connection duration between each pair of nodes. We use a contact matrix 𝐌 denoting the contact among nodes.𝑚_𝑖,𝑗(𝑡) is the cumulative contact duration between 𝑣_𝑖and𝑣_𝑗from 𝑇=0 to 𝑇=𝑡.

The study in [8] has studied the correlation between regularity and familiarity on Cambridge students, and it is observed that most of contacts among nodes reveal a short duration, while few of them have long duration, which is denoted as “community”. In this paper, we use 𝐌^′=[𝑚^′_𝑖,𝑗] to denote whether 𝑣_𝑖 and 𝑣_𝑗 have a contact duration higher than a threshold 𝛿⋅max(𝑚_𝑖,𝑗). Then, we cluster the attendants into several groups by their friendship graphs which are extracted from the two datasets as follows: 𝑚^′_𝑖𝑗=𝑚_𝑖𝑗,𝑚_𝑖𝑗≥𝛿⋅max(𝑚),0,𝑚_𝑖𝑗<𝛿⋅max(𝑚). (1)

3.3. Distribution of CCSC

We first construct a contact duration matrix 𝐌=[𝑚_𝑖,𝑗], where𝑚_𝑖,𝑗presents the history contact duration between𝑣_𝑖and𝑣_𝑗during the whole lifetime of the network (INFOCOM06:𝑇=[6207,340927]; SIGCOMM09:𝑇=[21,349811]). Without loss of generality, we denote𝐗and𝐘as two consecutive𝐌 and then compute the change of history contact (CHC), which is depicted as the distance of𝐗and𝐘using Distance(𝐗,𝐘)=_𝑗𝑖𝑠,𝑠=𝑖,𝑗𝑖,𝑗0,𝑋_𝑖𝑗=𝑌_𝑖𝑗,1,𝑋_𝑖𝑗≠𝑌_𝑖𝑗. (2)

The distribution of the distance is plotted in the log-log scale (Figure 1). The power-law distribution of intercontact time in the mobile social network is fully discussed in the existing literatures. However, the change of contacts in consecutive timestamps does not follow the power-law distribution. Then, we use 𝐌^′, where 𝑚^′_𝑖,𝑗 denotes whether a link between𝑣_𝑖and𝑣_𝑗is a CSC or not, and we compute the distance of two consecutive 𝐌^′; then, the CCSC at different timestamps is obtained (Figure 1(a)). The distribution of CCSC is plotted in Figure 1(b) using log-log scale. It is clear that the CCSC extracted from SIGCOMM09 follows the power-law distribution, ranging from 2 changes to 6 changes. In INFOCOM06, when the changes range from 2 to 7, the CCSC also follows the power-law distribution. The diversity of distribution between history contact duration and change of cumulative stable contact might be caused by removal of the temporary contact. Considering two people in the real world, the more familiar, the more stable their relationship is. Moreover, people denoted as “familiar” have longer contact duration and contact time, which has been proven in previous works. According to the discussion above, the CSC removes the temporary links among nodes.

(a)

(b)

Figure 1 

(a) Distribution of history contact duration. (b) Distribution of CCSC.

4. Community Core Evolution

In this section, we first introduce the community core detection algorithm and then discuss the community core tracking mechanism in mobile social networks.

4.1. Community Core Detection

Let us first discuss the topology change of the network, which is constantly updated by nodes and links changing through different timestamps. The increasing nodes or links can be decomposed as a sequence of node or link insertions, while the decreasing nodes or links can be decomposed as a sequence of node or link removals. We define four events that may cause the evolution of network: node add, node remove, link add, and link remove. However, in the definition above, the community core is based on links between two nodes. Hence, a single node without associated CSC cannot exist in the community core. Then, we refine the events as shown in Figure 2.

(a)

(b)

Figure 2 

Two events cause the structure variation of network. (a) A link between nodes𝑏and𝑐is added into the network because 𝑚′𝑏,𝑐>𝛿∗max(𝑚′). (b) A link between nodes𝑑and𝑒is removed from the network because 𝑚′𝑑,𝑒<𝛿∗max(𝑚′).

Link Add. The cumulative contact between 𝑣_𝑖 and 𝑣_𝑗 is higher than the current threshold; then link 𝑒_𝑖,𝑗 that is associated with two nodes 𝑣_𝑖 and 𝑣_𝑗 is added to a community core CO. Both 𝑣_𝑖 and 𝑣_𝑗 will be added to CO, even if any of them did not belong to CO.

Link Remove. The cumulative contact between 𝑣_𝑖 and 𝑣_𝑗 is lower than the current threshold; then link 𝑒_𝑖,𝑗 that is associated with two nodes 𝑣_𝑖 and 𝑣_𝑗 is removed from a community core CO. If 𝑣_𝑖 or 𝑣_𝑗 has no link associated with other nodes in CO, then the corresponding node will be removed from CO.

The basic operation procedure of community core detection at one timestamp is described in Figures 3 and 4. We extract the decreasing and increasing links at each timestamp and then use LRS and LAS to denote the decreasing link set and the increasing link set separately.

Figure 3 

Basic operation procedure of link remove.

Figure 4 

Basic operation procedure of link add.

Giving a certain community core partition, the Link Remove will result in deleting existing community cores (Figure 3), while Link Add will result in expanding the community core or inserting a new community core (Figure 4). The procedure can be divided into two phases. Firstly, we treat the Link Remove set and refine the existing community core through the existence of connected path. If there is no path connected, the link will be removed from CO. Secondly, by updating the max contact duration, addition link and its nodes will be added into the existing community core or a new community core.

4.2. Evolution of Community Core

In order to study the evolution process of community core, we should track the community core at each timestamp. How to distinguish two community cores in the consecutive timestamps is the biggest problem about tracking.

4.2.1. Model

According to Definition 3, the evolution of community core can be presented by CRS₀,CRS₁,…,CRS_𝑘,…. For a community core at 𝑇=𝑡, CRS(𝑡)={CO₀,CO₁,…,CO_𝑚}, and 𝐿(𝑡)={𝑙₀,𝑙₁,…,𝑙_𝑛} is denoted as the label set of community cores identifying a community core at 𝑇=𝑡 uniquely. In the previous literatures, there can be seen a broad consensus on the basic events that can be used to describe the evolution of dynamic communities [3, 7, 11]. We extend and specify these events as shown in Figure 5.

Figure 5 

Six events provide variation of community cores. The red solid/dash line denotes the link add/remove separately, and different colors mean different community cores.

Birth. It is the emergence of a new community core at 𝑇=𝑡+1, and there is no corresponding community core in CRS(𝑡). A community core CO_new which is labeled as 𝑙_new is created in CRS(𝑡+1) at 𝑇=𝑡+1, while CO_new∉CRS(𝑡). That is, for any 𝑙_new∈𝐿(𝑡+1), there is 𝑙_new∉𝐿(𝑡).

Death. It is the disappearance of a community core CO_old at 𝑇=𝑡+1 as CO_old exists in CRS(𝑡) at 𝑇=𝑡. There is no corresponding community core in CRS(𝑡+1). If we use 𝑙_old denoting core label of CO_old, then the death of a community core CO_old means𝑙_old∈𝐿(𝑡), and, for any𝑙_𝑠∈𝐿(𝑡+1), 𝑙_𝑠≠𝑙_old.

Merging. It means that two community cores merge into one community core at 𝑇=𝑡+1.

Splitting. A community core is divided into two separate community cores.

Growth. A node joins into a community core. And this will result in no changes between 𝐿(𝑡) and 𝐿(𝑡+1).

Contraction. A node moves out of a community core. This also will result in no changes between 𝐿(𝑡) and 𝐿(𝑡+1).

4.2.2. Tracking Community Cores

In the context of the model described above, the most important thing is to identify the changes of community cores. Three questions should be answered. (1) Where does the core come from? (2) What happened to community core after updating? (3) Where is the core going?

The study in [12] is concerned with tracking communities based on detected communities, using the Jaccard coefficient. Differing from this method, we track these cores by enhancing our algorithm. When the algorithm runs, the tracking process works simultaneously, which is triggered by the variation of links.

According to our algorithm, there exist only contact frequency between two core nodes lower than 𝛿⋅max(𝑚_𝑖,𝑗), and there is no other path connecting these two nodes in the original core; the splitting process will be triggered. Hence,𝑣_𝑖and𝑣_𝑗have their isolate core sets separately. We use node ID as the core label when creating a new community core. Initially, each node will be tagged a community label as itself. The benefits are as follows. Firstly, the finite namespace of core label will not cause muddle of naming. Secondly, community core can be tracked easier when a community core is created again. The tracking algorithm uses node ID as initial community core ID if the node is extracted to a community core, and when a node is removed from community core set, the node ID is restored.

Basic operation procedure of tracking is given as follows.

Switch (events) Case Birth (𝑣_𝑖 and 𝑣_𝑗 form a new core): 𝐿(𝑡+1)⟵𝑙_new,𝑙_new=𝑖or𝑗; (3) Case Death (CO_𝑖∈CRS(𝑡) but CO_𝑖∉CRS(𝑡+1)): Every node in CO_𝑖 labeled as its node ID. Case Merging (CO_𝑖 and CO_𝑗 merge into on core): Nodes with fewer core members change their IDs to the other core. Case Splitting (𝑣_𝑖 and 𝑣_𝑗 have no path to connect): Delete 𝑙_old in 𝐿(𝑡+1), and 𝐿(𝑡+1)←𝑖,𝑗, 𝑣_𝑖 and 𝑣_𝑗 change label as their node ID. Case Growth (𝑣_𝑖 join into an existing community core): 𝑣_𝑖 changes label as the community core. Case Contraction (𝑣_𝑖 moves out of community core): 𝑣_𝑖 changes label as its node ID.

5. Evaluation

In this section, we discuss the evolution of community core, which is detected and tracked by our algorithm. COPRA [13] is a well-known efficient algorithm of fast community detection, and we choose COPRA to compare with our algorithm.

5.1. Contact Variation

In order to reveal the community core evolution briefly, we first show the contact variation of both SIGCOMM09 and INFOCOM06 under the whole lifetime (Figure 6). Due to the difference of data preprocessing, SIGCOMM09 records the discrete contact time among nodes, while INFOCOM06 records the continuous contact time. According to the description of SIGCOMM09, each device performs a periodic Bluetooth device discovery every 120±10.24 seconds (randomized) for 10.24 seconds. When a device finds others, it records the current time. However, this mechanism can only record one contact time in a period for the same pair, which will miss some contact information. Hence, the total link change, link add, and link remove of SIGCOMM09 almost have no differences.

(a)

(b)

(c)

(d)

(e)

(f)

(g)

(h)

Figure 6 

Description of two datasets. SIGCOMM09 records the discrete contact time among nodes, while INFOCOM06 records the continuous contact time. (a) Total link number (SIGCOMM09), (b) total link number (INFOCOM06), (c) link add (SIGCOMM09), (d) link add (INFOCOM06), (e) link remove (SIGCOMM09), (f) link remove (INFOCOM06), (g) network feature (SIGCOMM09), and (h) network feature (INFOCOM06).

5.2. Change of 0-1 Contact Matrix

According to 𝐌^′, the 0-1 contact matrix 𝐁=[𝑏_𝑖,𝑗] can be obtained. 𝐌^′ changes when the time increases, and the maximum contact duration among nodes may be changed, which results in the variation of 𝐁. The change of 𝐁 during the whole collection procedure is plotted in Figure 7. Consider the following: 𝑏_𝑖𝑗=1,𝑚^′_𝑖𝑗≥𝛿⋅max𝑚^′,0,𝑚^′_𝑖𝑗<𝛿⋅max𝑚^′. (4)

(a)

(b)

(c)

(d)

(e)

(f)

(g)

(h)

Figure 7 

Number of changes in 0-1 matrix between two consecutive timestamps. Above: number of changes in SIGCOMM09 under 𝛿 = 0.2, 0.4, 0.6, and 0.8 (from (a) to (d)). Below: number of changes in INFOCOM06 under 𝛿 = 0.2, 0.4, 0.6, and 0.8 (from (e) to (h)).

As shown in Figure 7, most of the changes occur at the beginning of collection, and they are then gradually diminished over time. The number of changes reduces by the increasing of 𝛿. Meanwhile, in SIGCOMM09, the maximum changes of 0-1 contact matrix under 𝛿=0.2,0.4,0.6,0.8 are 8, 6, 4, and 2, respectively, while in INFOCOM06, the values are 12, 4, 2, and 2. With 𝛿 increasing, the maximum changes of 0-1 contact matrix are reduced.

5.3. Selected Node Count

One of the biggest differences between community and community core is the number of clustered nodes. In other words, the community core of a mobile social network is the subset of the whole community. According to previous works in [8], few of nodes can be classified as “familiar strangers” and “friends,” and nodes in the “community” are even less. Hence, only the node pairs which have high contact frequency can be selected to the community core.

Intuitively, improving 𝛿 will result in fewer selected contacts and nodes, which is illustrated in Figures 8(a) and 8(b). Let us first consider SIGCOMM09, when time goes by, the selected nodes become more and more stable. In the first day of data collection, the selected node changes dramatically, especially under the low 𝛿. Then, the stable duration of selected nodes prolonged, and the selected nodes no longer have change after about 2∗10⁵ seconds. Compared with different 𝛿, the lower 𝛿 will result in a higher selected nodes, which is meaningless for community cores (when 𝛿=0.2, during the data collection, the maximum selected nodes in SIGCOMM09 are 61, and the maximum selected nodes in INFOCOM06 are 71), while the higher the 𝛿 is, the fewer nodes are selected to construct the community core. A brief comparison of average selected nodes under different 𝛿 is depicted in Figure 8(c). The same as discussed above, the average of selected nodes decreases when 𝛿 increases. Although the selected nodes increase with the decreasing of 𝛿, the variation of selected nodes in INFOCOM06 still has little difference. Unlike SIGCOMM09 the selected nodes in INFOCOM06 change frequently, even at the end of the data collection. This phenomenon can reflect the fact that in SIGCOMM09, the “friends” of attendants are relatively stable, and participants usually contact with familiar people, while in INFOCOM06, contacts among strangers are more frequent than in SIGCOMM09; hence, the selected node changes more often. Nevertheless, the variation of selected nodes in SIGCOMM09 and INFOCOM06 is relatively stable after 2∗10⁵ seconds, which is important according to features of community core.

(a)

(b)

(c)

Figure 8 

Number of nodes in community core. (a) Variation in number of nodes in community core in SIGCOMM09. (b) Variation in number of nodes in community core in INFOCOM06. (c) Average number of nodes in community core in the two datasets under different 𝛿.

The number of nodes in communities detected by COPRA is depicted in Figure 9. Different from our algorithm, the number of nodes detected by COPRA is highly unstable. And the number of changes between two consecutive timestamps is also very large compared with our algorithm.

(a)

(b)

(c)

(d)

Figure 9 

Number of nodes in community detected by COPRA. (a) Node number at each timestamp in communities (SIGCOMM09). (b) Number of node changes in community between two consecutive timestamps (SIGCOMM09). (c) Node number at each timestamp in communities (SIGCOMM09). (d) Number of node changes in community between two consecutive timestamps (INFOCOM06).

5.4. Number of Community Cores

A community core set is composed of selected nodes, which divides a mobile social network into pieces of closely connected fragments. Hence, the community core number in a community set determines the fragmentation degree of this mobile social network. After running our algorithm, the community core count in each timestamp under different 𝛿 is obtained (Figure 10).

(a)

(b)

(c)

(d)

(e)

(f)

(g)

(h)

Figure 10 

Number of changes in core matrix between two consecutive timestamps. Above: number of changes in SIGCOMM09 under 𝛿 = 0.2, 0.4, 0.6, and 0.8 (from (a) to (d)). Below: number of changes in INFOCOM06 under 𝛿 = 0.2, 0.4, 0.6, and 0.8 (from (e) to (h)).

As depicted in Figure 11(a), after about 2∗10⁵ seconds, the community count under each different 𝛿 becomes fixed, which is the same as the selected nodes. However, the core number in INFOCOM06 is more complicated. Like the variation of selected node, the number of community core fluctuates with time changes; see Figure 11(b).

(a)

(b)

(c)

Figure 11 

Number of community cores. (a) Variation in number of community core in SIGCOMM09. (b) Variation in number of community cores in INFOCOM06. (c) Average number of community cores in the two datasets under different 𝛿.

As mentioned before, this is due to the frequent contact among strangers. In other words, attendants in SGICOMM09 have a more fixed social circle than in INFOCOM06. The last but the most important feature of community core count is that the core number is not monotonically changing with changes. We can see in Figure 11(c) that the maximum average core count (≈7.71) in SIGCOMM09 appears when 𝛿=0.2. After a reduction to 𝛿=0.4, the average core count rises approximate to 4.87 when 𝛿=5. The same phenomenon appears in INFOCOM06: the core count reaches the max value at 𝛿=4 (≈9.31). Then, it declines approximate to 8.4 at 𝛿=5 and grows approximate to 9.05 at 𝛿=6. The reason for this situation can be explained by two sides. On one hand, the higher will filter out more contacts, which makes more fragments of the mobile network and increases the number of community cores. On the other hand, some network fragments with low contact frequency will be moved out of the community core set entirely, which results in the reduction of cores. Hence, the number of cores fluctuates under the different.

Stability is very important to the community core. Compared with Figures 11 and 12, the community core is much more stable than traditional community detection algorithm. The number of communities detected by COPRA is depicted in Figure 12, which reveals high instability. And the number of changes between two consecutive timestamps is also very large compared with our algorithm.

(a)

(b)

(c)

(d)

Figure 12 

Number of communities detected by COPRA. (a) Number of communities at each timestamp (SIGCOMM09). (b) Number of community changes between two consecutive timestamps (SIGCOMM09). (c) Number of communities at each timestamp (INFOCOM06). (d) Number of community changes between two consecutive timestamps (INFOCOM06).

5.5. Change of Core Matrix

In order to evaluate the change of community core set between consecutive timestamps, we use the distance function discussed in Section 3.3 to illustrate the difference between consecutive community core sets.

The distance function requires that the two matrices have the same line and row number. However, the nodes and links in the community core set between consecutive timestamps are different. According to the tracking algorithm, nodes in the mobile social networks are assigned an initial community core label which is equal to their node ID. And the finite namespace of core label ensures that the label will not be beyond the scope of node ID. Then, we construct a community core matrix 𝐂𝐌=[𝑐𝑚_𝑖,𝑗], where 𝑐𝑚_𝑖𝑗=nodeID,𝑖,𝑗∉CRS,coreID,𝑖,𝑗∈CRS. (5)

Note that although node ID is considered in computation, it will not influence the final result of distance.

The distance under different 𝛿 is depicted in Figure 10. It can be observed that the majority of consecutive core matrices have no changes. Only few of them have 1 different element, and the variation of 2 elements is even less (Figure 13). With 𝛿 increasing, the variation of core matrix reduces accordingly. This illustrates that the higher the 𝛿 is, the more sensitive the community core becomes. Considering the variation time, most of the changes occur at the beginning of data collection, which is also consistent with the change of selected nodes and the core number.

Figure 13 

Number of changes in core matrix with different 𝛿.

5.6. Community Core Tracking

In this part, we focus on the visualization of community core evolution. First, we extract the core ID of each node from community core matrix. If a node does not belong to any cores, it is labeled as its node ID. Then, we get the community core at each timestamp. Finally, the ID including only one node is removed. The community core set extracted from the two datasets is presented in Figure 14. According to the selected node and the core number under the different 𝛿, we choose 𝛿=0.4 in SIGCOMM09 and 𝛿=0.6 in INFOCOM06 to display the evolution of community cores.

(a)

(b)

(c)

(d)

Figure 14 

(a) Original community core evolution in SIGCOMM09 with 𝛿=0.4. (b) Refined community core evolution in SIGCOMM09 with 𝛿=0.4. (c) Original community core evolution in INFOCOM06 with 𝛿=0.6. (d) Refined community core evolution in INFOCOM06 with 𝛿=0.6.

Figures 14(a) and 14(c) include nodes in the community cores and the noncore nodes. If a node does not belong to any community cores, its ID will be a straight line. Besides, if a node is selected as the community core, the ID will change to the core ID. Figures 14(b) and 14(d) are the refined core traces, including nodes belonging to the community cores only. Compared with Figure 11, the evolution of community cores appears directly.

6. Conclusions

In this paper, we mainly analyze the community core in mobile social networks. Firstly, the change of cumulative stable contact is discussed. And then, we propose the community core detection algorithm to extract the community core from two experimental mobile social networks. Finally, we introduce a label-based community core tracking algorithm, which can briefly display the evolution of community core. Compared with traditional community detection algorithms, we show that the community core extracted by our algorithm is stable and that it can be further used in network analysis in mobile social networks.

Acknowledgment

An earlier version of this paper was presented at the 2013 ASE/IEEE International Conference on Social Computing. This paper is being jointly supported in part by the National Natural Science Foundation of China under Grant nos. 61303062 and 60903225.