| ²é¿´: 3689 | »Ø¸´: 21 | |||
ssjcumtгæ (СÓÐÃûÆø)
|
[½»Á÷]
IEEE Comm. letter, rejected & resubmission allowed,Ð޸ĸå¿É³¬ËÄÒ³Âð£¿
|
||
|
°´ÕÕÉó¸åÈËÒªÇó¸Ð¾õ¿Ï¶¨ËÄÒ³²»¹»Óã¬Ð޸ĸå¿ÉÒÔ³¬¹ýËÄÒ³Â𣿠Èç¹û¸ÄͶ£¬ÕâÖÖËÄÎåÒ³µÄ¶ÌÎÄ»¹ÓÐÄÄЩÔÓÖ¾¿ÉÒÔ½ÓÊÕ£¿Çë´óÉñ°ï×ÅÍÆ¼ö¼¸¼Ò¡£ ÁíÍ⣬ÕâÖÖ rejected & resubmissinÓжà´óÏ£ÍûÄØ£¿ Èý¸öÉó¸åÈË£¬Ò»¸öÒâ¼ûÊÇ¡°the performance of the proposed protocol has to be compared with a benchmark scheme where the ¡£¡£¡£¡£¡£¡±£¬µ«ÊÇÕâ¸öreviewÒªÇó½øÐжԱȵÄÕâ¸öbenchmarkºÍÎÒµÄËäÈ»ÓеãÀàËÆ£¬µ«ÊÇÆäʵûÓÐʲô¿É±ÈÐÔ¡£ ÁíÍâÒ»¸ö˵Î񵀮äÖÐÒ»¸ö²ÎÊý¼ÙÉèµÄÌ«ÀíÏ뻯ÁË£¬²»Ì«ºÏÀí£¨ÆäʵÎÒÁíÍâһƪҲÊÇÕâ¸ö¼ÙÉ裬Éó¸åÈËҲû˵ʲô£©£¬Ò²Ìáµ½ÁËÒªÎÒ¸ú±ðÈ˵ķ½°¸È¥±È½Ï¡£ µÚÈý¸öÉó¸åÈËÒâ¼ûÌØ±ð¶à£¬Ð´ÁËÁ½Ò³£¬ÆäËûµÄÎÊÌâ¶¼ºÃ»Ø´ð£¬¾ÍÆäÖÐÒ»Ìõ±È½ÏÄѶԸ¶£¬ÊÇ˵ÎÒµÄΪʲôҪÕâô×ö£¿·½°¸ÎªÊ²Ã´ÕâôÉè¼Æ¡£ÆäʵûÓа취֤Ã÷Õâ¸ö·½°¸×îÓÅ£¬ÒòΪÎÒÊÇÊ×ÏÈÔÚÕâÖÖʵ¼Ê»·¾³ÏÂÌá·½°¸µÄ¡£ ¡°Ñо¿ÓÐûÓÐÒâÒ塱ÕâÖÖÎÊÌ⣬¿¼ÂǽǶȲ»Í¬£¬½áÂÛÒ²²»Í¬¡£ ÇëÎÊ´ó¼Ò£¬ÎÒÕâÖÖÇé¿ö£¬»¹ÓÐÐ޸ĵļÛֵô£¿¸Ð¾õÉó¸åÈ˶ÔÎÒµÄÑо¿ÁìÓò»¹Í¦ÊìϤ¡£Ïñ¡°the assumption seems too ideal.¡±£¬¡°the usefulness of the proposed protocol¡±ÕâÑùµÄÎÊÌ⣬Ӧ¸Ã´ÓÄĶùÈëÊÖÄØ£¿ ±à¼À´ÐÅÈçÏ£º Dear Author(s): The review of the referenced manuscript, CL2015-2411, is now complete. I regret to inform you that based on the enclosed reviews and my own reading of your manuscript, I am unable to recommend its publication in IEEE Communications Letters. You may revise and resubmit your manuscript to IEEE Communications Letters. When you do so, please include a cover letter that indicates the new submission is a revision of an earlier manuscript and the reference number of that prior manuscript. Also include as a supporting document a point-by-point response to the comments of the reviewers and the editor. The responses to comments file must be uploaded in PDF format in the same section in your submission as the body of your paper in ScholarOne Manuscripts, and not under the cover letter. Please also be aware that ALL submissions to IEEE Communications letters must complete the Electronic Copyright Process. If you decide to resubmit your manuscript you should complete the resubmission through the Manuscript Central. Click on "Manuscripts with Decisions" under My Manuscripts on the left side of your Author Dashboard and then click on "Create a Resubmission" under the Actions Column next to your manuscript. Your resubmission will be due within 75 days and is due on 10-Feb-2016. Please ensure that your revision is submitted in a timely manner as the web-based system will not allow a revision to enter the system after 75 days have elapsed. Please be aware that the time at which your revision permission will expire is 11:59 PM EST on the 75th day. Note, that according to the IEEE COMML policy, the maximum number of permitted resubmissions after a Reject-Resubmission Allowed decision is one (1) and the maximum number of permitted Minor Revisions is (2). Additional comments include: I have been able to obtain 3 reviews for this manuscript. Although the reviewers agree that this is an interesting work, they nevertheless provide comments for improving the manuscript and pinpoint some issues that need to be addressed. Addressing the reviewers\' comments requires a major revision of the manuscript. For the potential resubmission, please provide point-to-point responses to all of the reviewers\' concerns, and modify the paper where necessary. The reviewers\' comments are found at the end of this email. Thank you for submitting your work to the IEEE Communications Letters. Regards, Nikola Zlatanov Editor IEEE Communications Letters Reviewer: 1 Comments to the Author This paper investigates the performance analysis of a practical tow-way protocol which takes a joint consideration of the finite relay buffer, signalling overhead and lossy link. The basis of analysis is a Markov chain model of the proposed protocol. The paper is well-written and the analyses sound. The proposed protocol is very simple (which is good in part) and has to be compared with the best benchmark schemes in the literature. The author claim that the quality of the links are taken into account but it seems that the resulting contribution is very narrow in the proposed protocol. In fact, from Fig. 2, the relay always transmits if he has something in both queues. That is why the states (l,k) where both l and k are bigger than one do not exist. Therefore, the performance of the proposed protocol has to be compared with a benchmark scheme where the users and the relay are selected for transmission based on the qualities of the links (all states (l,k) are then present). It seems that reference [8] has already investigated this case for the ideal scenario where the signaling overhead is not taken into account. This protocol can serve at least as an upper bound. Reviewer: 2 Comments to the Author This paper considers a practical two-way relay protocol and proposes a Markov chain model to analyze this protocol. The closed form expressions for the throughput and delay are derived. I have the following comments. 1. In Section II-A, the authors propose a practical BNC protocol. However, it seems to me that it is just a threshold-based scheduling policy, where the threshold is 1 packet. The process of this protocol, e.g., waiting time slots, ACK/NACKs, is only an implementation of the threshold-based policy. Moreover, why the threshold is chosen to be 1 packet? Intuitively, the threshold should be chosen based on the link quality statistics, i.e., the successful packet rate in this manuscript. In addition, the Markov chain model and the analysis in the following sections highly depend on the protocol with this particular threshold. Therefore, the usefulness of the proposed protocol and the analysis in this manuscript appears to be questionable. 2. The authors state that they consider overflow probabilities in the abstract, the last paragraph in Section III, and the conclusion. However, throughout this manuscript, I cannot find any discussion or analysis about buffer overflow, which is an important issue in finite buffer systems. Actually, from the transition probability in Eq. (2), we can see that the impact of buffer overflow is ignored¡£ 3. According the BNC protocol and the Markov chain in Fig. 2, there are only 2(L+K) states. However, in Eq. (5), (7), and Eq. (8), it appears to me that the authors consider (L+1)¡Á(K +1) states. Please clarify it. 4.ÕâÒ»ÌõÊÇÒªÎÒÖ¤Ã÷Ò»¸ö¹«Ê½¡£ºÜÈÝÒ×¾ÍÖ¤Ã÷ÁË¡£ 5. Minor comments: 1) In the introduction, the definition of BNC and the difference between BNC and PNC are not clearly illustrated. 2) In Section II-A, the authors consider packet transmission, however, using the XOR operation in bit layer, i.e., BNC. Please clarify this confusion. 3) In Page 6/11, Line 14, what is the meaning of traditional scheduling? 4) In Section II-B, what is the duration of a time slot? Do you consider a slotted system? This should be introduced in Section II-A. 5) In Fig. 2, the two rightmost states in the first and second lines should be (0,K) and (1, K). 6) In Page 7/11, Line 34, the definitions of SiU and SiR can hardly be understood. 7) In Eq. (4), what are the state spaces of i and j? 8) In Page 7/11, Line 48, please specify the location of the method in [10]. 9) In Page 8/11, Line 18, the definition of the throughput is missing. 10) In Page 8/11, Line 18 and Line 24, what are the meanings of the duration of each packet and the average duration of one packet? 11) Section III is not well organized. I suggest the authors to summarize the results for the symmetric case in a lemma. 12) In Eq. (18), what is the summation taken over? Reviewer: 3 Comments to the Author This paper studied two-way relay channel with finite relay buffer using Markov model. However, the following questions should be carefully revised. First, a lot of works investigated the buffering with network coding by using Markov method. So the differences of the work compared with existing ones should be clearly summarized in order to outline the contribution of the paper. Second, it is assumed that A and B has infinite buffer and always has data to be transmitted. Compared with some existing works, where the sources were assumed with finite buffer or with some stochastic data arriving, the assumption in this paper seems too ideal. Thirdly, more simulation results on comparison with other protocols with network coding and buffering should be provided. Fourthly, the protocol in this paper should be described more clearly. For example, the description of ¡°In contrast to the traditional scheduling, the scheduling messages in this protocol are replaced by the waiting timeslot, and the ACK/NACKs from R to A and B are piggybacked by the next packets. These can save a considerable signaling overhead (the preamble).¡± is not clear enough. |
» ²ÂÄãϲ»¶
µ÷¼Á
ÒѾÓÐ6È˻ظ´
348·Ö»·¾³¹¤³Ì¡¤µ÷¼Á
ÒѾÓÐ7È˻ظ´
0835ѧ˶299Çóµ÷¼Á 08´óÀà¿É½ÓÊÜ
ÒѾÓÐ3È˻ظ´
357Çóµ÷¼Á
ÒѾÓÐ10È˻ظ´
²ÄÁÏ334Çóµ÷¼Á
ÒѾÓÐ7È˻ظ´
286Çóµ÷¼Á
ÒѾÓÐ8È˻ظ´
353Çóµ÷¼Á
ÒѾÓÐ3È˻ظ´
288Çóµ÷¼Á Ò»Ö¾Ô¸¹þ¹¤´ó ²ÄÁÏÓ뻯¹¤
ÒѾÓÐ6È˻ظ´
297Çóµ÷¼Á
ÒѾÓÐ7È˻ظ´
²ÄÁÏ295
ÒѾÓÐ9È˻ظ´
» ±¾Ö÷ÌâÏà¹Ø¼ÛÖµÌùÍÆ¼ö£¬¶ÔÄúͬÑùÓаïÖú:
IEEE Comm. letter, rejected & resubmission allowed, Çë½ÌÐ޸ĸåÉÏ´«ÐÎʽ£¿
ÒѾÓÐ4È˻ظ´
IEEE (COMM. Lett.)Ͷ¸å¾Ñé
ÒѾÓÐ24È˻ظ´
Awaiting Reviewer SelectionÁ½ÖÜÁËÄܲ»ÄÜÁªÏµÒ»ÏÂeditor
ÒѾÓÐ4È˻ظ´
ÎҺ܇å~ ֮ǧÍò±ðѧÎÒ(5), µ± reviewer µÄÐÄ·Àú³Ì (Öм¶Ñ§Õ߱ؿ´ÐĵÃ)¡ª ×ÔÎÒÐÐÏúƪ
ÒѾÓÐ41È˻ظ´
Ieee wireless communications letters ÊÇSCI ô
ÒѾÓÐ2È˻ظ´
¾Ñé·ÖÏí,IEEE Trans On CAS PAR II.
ÒѾÓÐ11È˻ظ´
Öйú¼ÆËã»úѧ»áÍÆ¼ö¹ú¼ÊѧÊõ¿¯ÎïÓë»áÒéÍøÂçÓëÐÅÏ¢°²È«
ÒѾÓÐ0È˻ظ´
IEEE SPL ÂÛÎı»¾Ü
ÒѾÓÐ8È˻ظ´
¡¾×ªÌû¡¿TD-LTE³É¹¦½«¸øWiMAXÖÂÃüÒ»»÷£ºÏÈ·¢ÓÅÊÆ½¥Ê§
ÒѾÓÐ5È˻ظ´
¡¾×ªÌû¡¿40G/100GÒÔÌ«Íø±ê×¼ÖÆ¶©ÕýʽÆô¶¯
ÒѾÓÐ1È˻ظ´
whcyb
ľ³æ (СÓÐÃûÆø)
- Ó¦Öú: 0 (Ó×¶ùÔ°)
- ½ð±Ò: 1368.1
- É¢½ð: 2200
- ºì»¨: 1
- Ìû×Ó: 185
- ÔÚÏß: 191.4Сʱ
- ³æºÅ: 2785795
- ×¢²á: 2013-11-07
- ÐÔ±ð: GG
- רҵ: ͨÐÅÀíÂÛÓëϵͳ
¡ï ¡ï ¡ï
Сľ³æ: ½ð±Ò+0.5, ¸ø¸öºì°ü£¬Ð»Ð»»ØÌû
ssjcumt: ½ð±Ò+2, ´óÐÞÒѾ»ØÀ´ÁË£¬ÏÖÔÚÔÚСÐÞÖÐ 2016-02-02 17:50:56
Сľ³æ: ½ð±Ò+0.5, ¸ø¸öºì°ü£¬Ð»Ð»»ØÌû
ssjcumt: ½ð±Ò+2, ´óÐÞÒѾ»ØÀ´ÁË£¬ÏÖÔÚÔÚСÐÞÖÐ 2016-02-02 17:50:56
|
ÕâÖÖÇé¿ö¾ÍÊÇ´óÐÞ£¬ºÃºÃ¸Ä»á½ÓÊյ쬽¨Òé¸ÄºóÖØÍ¶ ·¢×ÔСľ³æAndroid¿Í»§¶Ë |

2Â¥2015-12-02 17:42:52
zbconquer
ľ³æ (ÕýʽдÊÖ)
- Ó¦Öú: 77 (³õÖÐÉú)
- ½ð±Ò: 1901.1
- É¢½ð: 1105
- ºì»¨: 25
- Ìû×Ó: 843
- ÔÚÏß: 411.7Сʱ
- ³æºÅ: 693619
- ×¢²á: 2009-01-16
- ÐÔ±ð: GG
- רҵ: ͨÐÅÀíÂÛÓëϵͳ
¡ï
Сľ³æ: ½ð±Ò+0.5, ¸ø¸öºì°ü£¬Ð»Ð»»ØÌû
Сľ³æ: ½ð±Ò+0.5, ¸ø¸öºì°ü£¬Ð»Ð»»ØÌû
|
ÕâÒâ¼û»¹²»Ò»Ö°¡£¬»ù±¾¾ÍÊǽÓÊÕÁË¡£ ¹§Ï² Ö»ÐèÒª»Ø¸´ÏÂreviewer2¾ÍÐУ¬²»ÓÃ¹ÜÆäËûÁ½¸öreviewer£¬°´ÕÕreviewer2µÄÒâ¼ûÔÙÐÞÕýһϾͿÉÒÔÁË¡£ Ò»°ãÕâÖÖÇé¿ö£¬editior¿´Ò»¿´¾ÍÍêÁË£¬ºÜÉÙÔÙ·µ»Ø¸øreviewerÁË£¬µ±È»Ò²²»»áÔÙ·µ»Ø¸øreviewer 1 ºÍ 3ÁË¡£ |
18Â¥2016-01-30 21:28:39
ÄäÃû
Óû§×¢Ïú (ÖøÃûдÊÖ)
- Ó¦Öú: 131 (¸ßÖÐÉú)
- ½ð±Ò: 58.2
- É¢½ð: 647
- ºì»¨: 21
- Ìû×Ó: 1540
- ÔÚÏß: 578.2Сʱ
- ³æºÅ: 0
- ×¢²á: 2012-02-12
- ÐÔ±ð: GG
- רҵ: ͨÐÅÀíÂÛÓëϵͳ
3Â¥2015-12-02 19:31:33
whcyb
ľ³æ (СÓÐÃûÆø)
- Ó¦Öú: 0 (Ó×¶ùÔ°)
- ½ð±Ò: 1368.1
- É¢½ð: 2200
- ºì»¨: 1
- Ìû×Ó: 185
- ÔÚÏß: 191.4Сʱ
- ³æºÅ: 2785795
- ×¢²á: 2013-11-07
- ÐÔ±ð: GG
- רҵ: ͨÐÅÀíÂÛÓëϵͳ
¡ï
Сľ³æ: ½ð±Ò+0.5, ¸ø¸öºì°ü£¬Ð»Ð»»ØÌû
Сľ³æ: ½ð±Ò+0.5, ¸ø¸öºì°ü£¬Ð»Ð»»ØÌû
|
editorÒ»°ã²»»áÓÐÆ«¼ûµÄ°É¡£ÁíÍ⣬ÄãÈ·¶¨Óʼþ³ËÍµÄÆäËûÈ˲»ÊÇÖ÷±àºÍadm£¿Ë«Ã¤ÉóµÄÆÚ¿¯Ôõô»á°ÑÉó¸åÈ˵ÄÓʼþµØÖ·¸øÄã¿´µ½~~Ŀǰ½ÓÊÕ¶ÌÎĵÄÖªµÀµÄÖ»ÓÐTVT£¨6Ò³£©£¬Spl£¬ieee wireless communication letter£¨·Çsci£¬´´¿¯Ê±¼äÌ«¶Ì£¬µ«¼ìË÷³ÙÔçµÄÊ£©£¬»¹ÓÐÒ»¸öÊÇieice t communication(15Äê10ÔÂ1ºÅ¿ªÊ¼½ÓÊÕËÄÒ³£¬Òª²îÒ»µã£¬ÈÕ±¾µÄ£¬·¢ÎÄÒª»áÔ±)¡£ËùÒÔ£¬»¹Êǽ¨Òé¸Ä¸ÄÖØÍ¶°É£¬°ÑһЩ²»ÖØÒªµÄÒªÉáµÃɾ£¬¾«¼òһϡ£ÖеĸÅÂÊ»¹ÊǷdz£¸ßµÄ¡£ ·¢×ÔСľ³æAndroid¿Í»§¶Ë |

7Â¥2015-12-02 21:12:55
zbconquer
ľ³æ (ÕýʽдÊÖ)
- Ó¦Öú: 77 (³õÖÐÉú)
- ½ð±Ò: 1901.1
- É¢½ð: 1105
- ºì»¨: 25
- Ìû×Ó: 843
- ÔÚÏß: 411.7Сʱ
- ³æºÅ: 693619
- ×¢²á: 2009-01-16
- ÐÔ±ð: GG
- רҵ: ͨÐÅÀíÂÛÓëϵͳ
¡ï ¡ï ¡ï ¡ï
Сľ³æ: ½ð±Ò+0.5, ¸ø¸öºì°ü£¬Ð»Ð»»ØÌû
ssjcumt: ½ð±Ò+3, ´óÉñµÄ»Ø¸´ºÜÓаïÖú 2016-01-06 12:31:33
Сľ³æ: ½ð±Ò+0.5, ¸ø¸öºì°ü£¬Ð»Ð»»ØÌû
ssjcumt: ½ð±Ò+3, ´óÉñµÄ»Ø¸´ºÜÓаïÖú 2016-01-06 12:31:33
|
cover letterÖ÷ÒªÊǸøeditor¿´µÄ£¬×ܽá¸Ä¶¯Çé¿ö¡£ ¸øreviewerµÄresponseÖÐ×îºÃдÇå³þ£¬ËûµÄÕâÌõcommentsÊÇÔõôincorporateµ½revised versionÖеģ¨ÓÃÑÕÉ«highlight¸Ä¶¯£© |
9Â¥2015-12-02 21:58:42
zbconquer
ľ³æ (ÕýʽдÊÖ)
- Ó¦Öú: 77 (³õÖÐÉú)
- ½ð±Ò: 1901.1
- É¢½ð: 1105
- ºì»¨: 25
- Ìû×Ó: 843
- ÔÚÏß: 411.7Сʱ
- ³æºÅ: 693619
- ×¢²á: 2009-01-16
- ÐÔ±ð: GG
- רҵ: ͨÐÅÀíÂÛÓëϵͳ
¡ï
Сľ³æ: ½ð±Ò+0.5, ¸ø¸öºì°ü£¬Ð»Ð»»ØÌû
Сľ³æ: ½ð±Ò+0.5, ¸ø¸öºì°ü£¬Ð»Ð»»ØÌû
|
EditorÊÇNikola Zlatanov£¬µ±È»¶Ôfinite relay bufferÊìÁË¡£ CL³ýÁËÊÕ¾ÍÊǾݣ¬¾Ý»¹°üÀ¨ÔÊÐíÖØÍ¶ºÍ²»ÔÊÐíÖØÍ¶¡£ ÔÊÐíÖØÍ¶²î²»¶à¾ÍÊÇ´ó¸ÄÁË£¨editorµÄÓʼþÀïÒ²ÁËmajor revision£© ÒýEICºÍmanaging editorµÄÂÛÎÄÄÜÓÐɶÓᣡ£¡£ |
10Â¥2015-12-02 22:02:11
zldrobit
гæ (³õÈëÎÄ̳)
- Ó¦Öú: 0 (Ó×¶ùÔ°)
- ½ð±Ò: 16
- Ìû×Ó: 11
- ÔÚÏß: 14.7Сʱ
- ³æºÅ: 2633208
- ×¢²á: 2013-09-03
- רҵ: ͨÐÅÀíÂÛÓëϵͳ
¡ï
Сľ³æ: ½ð±Ò+0.5, ¸ø¸öºì°ü£¬Ð»Ð»»ØÌû
Сľ³æ: ½ð±Ò+0.5, ¸ø¸öºì°ü£¬Ð»Ð»»ØÌû
|
ÎҼǵÃÎÒÖØÍ¶CLµÄʱºòÊǰ´ÕÕÉó¸åÈ˵ÄÒâ¼û±È½ÏÁ˱ðÈ˵ÄprotocolµÄ£¬ÐÔÄÜûÓбðÈ˺㬲»¹ýÔÚresponseºÍÐÞ¸ÄmanuscriptµÄintroductionÀï˵Ã÷ÁËÔÒò£º¼´Ê¹±ðÈËprotocolµÄÍÌÍÂÁ¿±È×Ô¼ºµÄ´ó£¬µ«ÊÇͬʱ±ðÈ˵ĿªÏúÌØ±ð´ó¡£Ï£ÍûÄܸøÂ¥Ö÷Ò»µã°ïÖú¡£¡£¡£ ÁíÍâ¹ØÓÚCLÏÞÖÆ4Ò³³¤¶ÈµÄÎÊÌ⣬ºÃÏñͶ¸åϵͳÊDz»Ö§³Ö³¤ÓÚ4Ò³µÄÎÄÕµġ£ µ«ÊÇÎÒ×Ô¼ºµÄ¾Í±È4Ò³³¤£¬ºóÀ´ÊÇÓÃÁËlatexµÄ°üËõ¼õÁ˺ܶà¿Õ°×£¬£¨ÀýÈ磺ͼºÍ±êÌ⣬±êÌâºÍÕýÎÄÖ®¼ä£©²ÅÅŵ½4Ò³µÄ£¬Â¥Ö÷Ò²¿ÉÒÔÊÔÒ»ÏÂÄØ¡£ ps:×Ô¼ºµÄCLÖØÍ¶»¹Ã»ÓÐ×îÖÕ½á¹ûÄØ¡£¡£¡£ |
13Â¥2016-01-04 14:31:04
zbking
Ìú¸Ëľ³æ (ÕýʽдÊÖ)
- Ó¦Öú: 46 (СѧÉú)
- ½ð±Ò: 10225.9
- É¢½ð: 19
- ºì»¨: 8
- Ìû×Ó: 875
- ÔÚÏß: 867.1Сʱ
- ³æºÅ: 2524034
- ×¢²á: 2013-06-27
- ÐÔ±ð: GG
- רҵ: ¼ÆËã»úÍøÂç
¡ï
Сľ³æ: ½ð±Ò+0.5, ¸ø¸öºì°ü£¬Ð»Ð»»ØÌû
Сľ³æ: ½ð±Ò+0.5, ¸ø¸öºì°ü£¬Ð»Ð»»ØÌû
|
Èç¹ûÎÄÕÂÖÊÁ¿¹ýÓ²µÄ»°£¬¸ù±¾¾Í²»ÓùÜÒýÓÃʲô±à¼»òÕßÖ÷±àµÄÂÛÎÄ£¨Èç¹ûÈ˼ÒûÖ÷¶¯Ìß³öÀ´µÄ»°£©£¬»òÕßһЩÆäËüÆßÀï°ËÀïµÄ£»ÐÞ¸ÄÌṩ°ïÖúµÄ»°ÔÙ×îÖÕ°æÀïÃæ¸ÐлϾÍÊÇÁË£¨Èç¹û¼Óã©£¬ÖÁÓÚCover LetterÌá²»Ìá¸ù±¾Ã»±ØÒª£¬¿öÇұ༺ÍÄǸö×÷ÕßÒ²Ö»ÊǺÏ×÷¹ØÏµ£¬ÉõÖÁÓÚ¿ÉÄÜûÄÇôÊ죬ÎÄÕµÄ×îÖÕÃüÔË»¹ÊÇ¿´Éó¸åÈË»ØÀ´µÄÒâ¼û£¬Â¥Ö÷ÏëµÄÌ«¶àÁË¡£¡£¡£ |
15Â¥2016-01-06 14:49:57
ssjcumt
гæ (СÓÐÃûÆø)
- Ó¦Öú: 1 (Ó×¶ùÔ°)
- ½ð±Ò: 50.9
- É¢½ð: 120
- Ìû×Ó: 167
- ÔÚÏß: 48.2Сʱ
- ³æºÅ: 1420773
- ×¢²á: 2011-09-28
- רҵ: ͨÐÅÀíÂÛÓëϵͳ
19Â¥2016-03-04 21:11:01
ssjcumt
гæ (СÓÐÃûÆø)
- Ó¦Öú: 1 (Ó×¶ùÔ°)
- ½ð±Ò: 50.9
- É¢½ð: 120
- Ìû×Ó: 167
- ÔÚÏß: 48.2Сʱ
- ³æºÅ: 1420773
- ×¢²á: 2011-09-28
- רҵ: ͨÐÅÀíÂÛÓëϵͳ
|
resubmissionµÄʱºò£¬»¹Êǵ¥Ë«À¸¶¼ÒªÓаɣ¿£¨µ¥À¸±ãÓÚÉó¸å£¬Ë«À¸ÊÇÕýʽµÄ£©¡£ ¼ÙÈçÎÒΪÁËѹËõµ½ËÄÒ³£¬¶ø°ÑһЩ¶ÎÂä½øÐо«¼òѹËõ£¬ÄÇôÕâЩ±ä¶¯£¨²»ÊÇresponse£©£¬»¹ÐèҪעÃ÷Â𣿠Èç¹ûÐèҪעÃ÷µÄ»°£¬ÊÇÔÚresponseÎĵµÀïÃæÄØ£¬»¹ÊÇcover letterÀïÃæÄØ£¿ÒòΪÕâЩ±ä¶¯²»ÊÇÕë¶Ôijһ¸öreviewerµÄ¡£ ÁíÍ⣬Õë¶ÔreviewerµÄresponseÐèÒªÔÚÔÎÄÖÐhightlightÂ𣿱ÈÈçºìÉ«×ÖÌåÖ®ÀàµÄ¡£ |
4Â¥2015-12-02 20:13:17
ssjcumt
гæ (СÓÐÃûÆø)
- Ó¦Öú: 1 (Ó×¶ùÔ°)
- ½ð±Ò: 50.9
- É¢½ð: 120
- Ìû×Ó: 167
- ÔÚÏß: 48.2Сʱ
- ³æºÅ: 1420773
- ×¢²á: 2011-09-28
- רҵ: ͨÐÅÀíÂÛÓëϵͳ
5Â¥2015-12-02 20:19:21
ssjcumt
гæ (СÓÐÃûÆø)
- Ó¦Öú: 1 (Ó×¶ùÔ°)
- ½ð±Ò: 50.9
- É¢½ð: 120
- Ìû×Ó: 167
- ÔÚÏß: 48.2Сʱ
- ³æºÅ: 1420773
- ×¢²á: 2011-09-28
- רҵ: ͨÐÅÀíÂÛÓëϵͳ
|
¶àл¹þ¡£ ËùÓеÄreviewer¶¼Ã»ÓÐÖ±½Ó˵reject£¬Ö»ÊÇ˵ÐèÒª×öÄÇЩ¸Ä¶¯ÄÇЩ²¹³ä¡£µ«ÊÇeditor»¹ÊÇrejectÁË£¬ÁíÍ⣬ÎÒÈÏʶÕâ¸öeditor£¨Ëû²»ÈÏʶÎÒ¹þ£©£¬Ëû¶ÔÎÒÕâ¿éͦÊìµÄ¡£editorÊDz»ÊÇÓÐÆ«¼ûÄØ£¿ Óʼþ³Ë͸øÁËÈý¸öÈË£¬Ò»¸ö¸øeditor-in-chief£¬Ò»¸ö¸ømanaging editor£¬Ò»¸ö¸øËû×Ô¼º£¬Èç¹ûÎÒÒýÓÃÁ½ÆªËûÃǵÄÎÄÕ»᲻»á¶Ô½ÓÊÕÓаïÖú£¿ |
6Â¥2015-12-02 20:38:47
whcyb
ľ³æ (СÓÐÃûÆø)
- Ó¦Öú: 0 (Ó×¶ùÔ°)
- ½ð±Ò: 1368.1
- É¢½ð: 2200
- ºì»¨: 1
- Ìû×Ó: 185
- ÔÚÏß: 191.4Сʱ
- ³æºÅ: 2785795
- ×¢²á: 2013-11-07
- ÐÔ±ð: GG
- רҵ: ͨÐÅÀíÂÛÓëϵͳ
¡ï
Сľ³æ: ½ð±Ò+0.5, ¸ø¸öºì°ü£¬Ð»Ð»»ØÌû
Сľ³æ: ½ð±Ò+0.5, ¸ø¸öºì°ü£¬Ð»Ð»»ØÌû
|
¸Ï½ôÏ×ÉÏÄãµÄÏ¥¸Ç¸øeditor°É£¬·ÅÐĴ󵨵ÄÒý°É ·¢×ÔСľ³æAndroid¿Í»§¶Ë |

8Â¥2015-12-02 21:42:40














»Ø¸´´ËÂ¥
