<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc7548 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7548.xml">
<!ENTITY rfc7326 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7326.xml">
<!ENTITY rfc2460 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY rfc4944 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">

<!ENTITY id.draft-ietf-6tisch-6top-sf0 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-6tisch-6top-sf0-02.xml">
<!ENTITY id.draft-satish-6tisch-6top-sf1 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-satish-6tisch-6top-sf1-02.xml">
]>
<rfc category="info" docName="draft-sajjad-6lo-wban-00" ipr="trust200902">
    
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
  <!-- used by XSLT processors -->
  <!-- For a complete list and description of processing instructions (PIs),
   please see http://xml.resource.org/authoring/README.html. -->
  <!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
   (Here they are set differently than their defaults in xml2rfc v1.32) -->
  <?rfc strict="yes" ?>
  <!-- give errors regarding ID-nits and DTD validation -->
  <!-- control the table of contents (ToC) -->
  <?rfc toc="yes"?>
  <!-- generate a ToC -->
  <?rfc tocdepth="4"?>
  <!-- the number of levels of subsections in ToC. default: 3 -->
  <!-- control references -->
  <?rfc symrefs="yes"?>
  <!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
  <?rfc sortrefs="no" ?>
  <!-- sort the reference entries alphabetically -->
  <!-- control vertical white space
   (using these PIs as follows is recommended by the RFC Editor) -->
  <?rfc compact="no" ?>
  <!-- do not start each main section on a new page -->
  <?rfc subcompact="no" ?>
  <!-- keep one blank line between list items -->
  <!-- end of list of popular I-D processing instructions -->

  <!-- ***** FRONT MATTER ***** -->
  <front>
      <!-- The abbreviated title is used in the page header - it is only necessary if the
       full title is longer than 39 characters -->

    <title abbrev="IPv6 over WBANs">Transmission of IPv6 Packets over Wireless Body Area Networks (WBANs)</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->
    <!-- Another author who claims to be an editor -->
    <author fullname="Muhammad Sajjad Akbar" initials="MS." surname="Akbar">
        <organization>Bournemouth University</organization>

        <address>
            <postal>
                <street>Fern Barrow, Dorset</street>
                <!-- Reorder these if your country does things differently -->
                <city>Poole</city>
                <region></region>
                <code>BH12 5BB</code>
                <country>United Kingdom</country>
            </postal>
            <email>makbar@bournemouth.ac.uk</email>
            <!-- uri and facsimile elements may also be added -->
        </address>
    </author>

  	<author initials='R.N.B.' surname="Bin Rais" fullname='Naveed Bin Rais'>
    		<organization>Ajman University</organization>
    		<address>
      	<postal>
					<street>University Street,Al jerf 1</street>
        	<code>346</code>
					<city>Ajman</city>
					<country>United Arab Emirates</country>
      	</postal>
      	<email>naveedbinrais@gmail.com</email>
    		</address>
  	</author>

	<author fullname="Abdur Rashid Sangi" initials="AR." surname="Sangi">
		<organization>Individual Contributor</organization>
		<address>
			<email>sangi_bahrian@yahoo.com</email>
		</address>
    </author>

	<author fullname="Mingui Zhang" initials="M." surname="Zhang">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>No. 156 Beiqing Rd. Haidian District</street>
          <!-- Reorder these if your country does things differently -->
          <city>Beijing</city>
          <region/>
          <code>100095</code>
          <country>China</country>
        </postal>
       <phone/>
      <email>zhangmingui@huawei.com</email>
      <!-- uri and facsimile elements may also be added -->
      </address>
    </author>	

	    <author fullname="Charles E. Perkins" initials="C.E." surname="Perkins">
      <organization>Futurewei</organization>
      <address>
        <postal>
          <street>2330 Central Expressway</street>
          <!-- Reorder these if your country does things differently -->
          <city>Santa Clara</city>
          <region/>
          <code>95050</code>
          <country>Unites States</country>
        </postal>
        <phone/>
        <email>charliep@computer.org</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date/>
    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
     in the current day for you. If only the current year is specified, xml2rfc will fill
	 in the current day and month for you. If the year is not the current one, it is
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to
	 specify just the year. -->
    
    <!-- Meta-data Declarations -->
    <area>Internet</area>
    
    <workgroup>6Lo Working Group</workgroup>
    
    <!-- WG name at the upperleft corner of the doc,
     IETF is fine for individual submissions.
	 If this element is not present, the default is "Network Working Group",
     which is used by the RFC Editor as a nod to the history of the IETF. -->
    
    <keyword>Internet Draft</keyword>
    
    <!-- Keywords will be incorporated into HTML output
     files in a meta tag but they have no effect on text or nroff
     output. If you submit your draft to the RFC Editor, the
     keywords will be used for the search engine. -->

    <abstract>
      <t>Wireless Body Area Networks (WBANs) intend to facilitate use cases 
	  related to medical field. IEEE 802.15.6 defines PHY and MAC layer and is 
	  designed to deal with better penetration through the human tissue without 
	  creating any damage to human tissues with the approved MICS (Medical 
	  Implant Communication Service) band by USA Federal Communications 
	  Commission (FCC). Devices in WBANs conform to this IEEE standard.</t>
	  <t>This specification defines details to enable transmission of IPv6 
	  packets, method of forming link-local and statelessly autoconfigured IPv6 
	  addresses on WBANs.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
		<t>Wireless Body Area Networks (WBANs) are comprised of devices that 
		conform to the <xref target="IEEE802.15.6"></xref>, standard by the IEEE. 
		IEEE 802.15.6 provides specification for the MAC layer to access the 
		channel. The coordinator divides the channel into superframe time 
		structures to allocate resources <xref target="SURVEY-WBAN"></xref>
		<xref target="MAC-WBAN"></xref>. Superframes are bounded by 
		equal length beacons through the coordinator. Usually beacons are sent 
		at beacon periods except inactive superframes or limited by regulation. 
		This standard works under following three channel access modes.</t>

		<t>Task group for 802.15.6 was established by IEEE in November 2007 for 
		standardisation of WBANs and it was approved in 2012. This standard 
		works in and around human body and focus on operating at lower 
		frequencies and short range. The focus of this standard is to design a 
		communication standard for MAC and physical layer to support different 
		applications, namely, medical and no-medical applications. Medical 
		applications refer to collection of vital information in real time 
		(monitoring) for diagnoses and treatment of various diseases with help 
		of different sensors (accelerometer, temperature, BP and EMG etc.). It 
		defines a MAC layer that can operate with three different PHY layers 
		i.e. human body communication (HBC), ultra-wideband (UWB) and Narrowband 
		(NB). IEEE 802.15.6 provides specification for MAC layer to access the 
		channel. The coordinator divides the channel into superframe time 
		structures to allocate resources. Superframes are bounded by equal 
		length beacons through coordinator. The purpose of the draft is to 
		highlight the need of IEEE 802.15.6 for WBASNs and its integration 
		issues while connecting it with IPv6 network. The use cases are provided 
		to elaborate the scenarios with implantable and wearable biomedical 
		sensors. 6lowpan provides IPv6 connectivity for IEEE 802.15.4; however, 
		it will not work with IEEE 802.15.6 due to the difference in frame 
		format in terms of size and composition.</t>  
    </section>

    <section title="Conventions and Terminology">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
	  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
	  document are to be interpreted as described in <xref target="RFC2119">
	  </xref>.</t>
    </section>

	<section title="Use cases for IEEE 802.15.6">			
			
			<section title="Hospital Patient Monitoring">
				<t>In the hospital environment, several levels of patient 
				monitoring services are required as different patients needs 
				different monitoring services e.g., a patient in Intensive Care 
				Unit (ICU) requires high prioritized periodic data services with 
				limited delay and high throughput than the patient in a normal 
				ward. Usually, a patient is equipped with multiple sensors that 
				measure vital signals like heart activity, muscle movements, 
				blood pressure, body oxygen level and brain stimulation via 
				integrated sensors i.e., (Electrocardiography), BP (Blood 
				Pressure) monitor, EMG (Electromyography), pulse oximeter and 
				EEG (Electroencephalography) etc. These sensors are categorized 
				as wearable and implantable sensors, hence we are assuming that 
				equipped sensors are mixture of wearable and implantable sensors which creates 
				restriction to use IEEE 802.15.6 as it is designed to deal with 
				better penetration through the human tissue without creating any 
				damage to human tissues with the approved MICS band by USA 
				Federal Communications Commission (FCC). In a hospital use case 
				scenario, the initial data generated by numerous biomedical 
				sensor nodes is collected by a central coordinator.</t>
				
				<t>In this case, Table 3 presents the summary of traffic 
				patterns for different biomedical sensor nodes attached to human 
				body with data generation rate, required data rate from channel 
				and QoS requirements.</t>				
				
				<texttable anchor="table_TRAFFIC" title="Traffic patterns and requirements of sensor nodes">
					<ttcol align='center'>Sensor Nodes</ttcol>
					<ttcol align='center'>Data Generation Interval</ttcol>
					<ttcol align='center'>Required Data Rate (Kbps)</ttcol>
					<ttcol align='center'>Delay Requirement</ttcol>
					<ttcol align='center'>Power Consumption</ttcol>
					<ttcol align='center'>Reliability Requirement</ttcol>					
					<c>ECG</c>
					<c>4 ms</c>
					<c>34</c>
					<c>&lt;125ms</c>
					<c>Low</c>
					<c>High</c>
					
					<c>EMG</c>
					<c>6 ms</c>
					<c>19.6</c>
					<c>&lt;125ms</c>
					<c>Low</c>
					<c>High</c>

					<c>EEG</c>
					<c>4 ms</c>
					<c>19.6</c>
					<c>&lt;125ms</c>
					<c>Low</c>
					<c>High</c>

					<c>SpO2 (Pulse Oximeter)</c>
					<c>10 ms</c>
					<c>13.2</c>
					<c>&lt;250ms</c>
					<c>Low</c>
					<c>Medium</c>

					<c>BP</c>
					<c>10 ms</c>
					<c>13.2</c>
					<c>&lt;250ms</c>
					<c>Medium</c>
					<c>Medium</c>

					<c>Respiration</c>
					<c>40 ms</c>
					<c>3.2</c>
					<c>&lt;250ms</c>
					<c>Medium</c>
					<c>Medium</c>

					<c>Skin temperature</c>
					<c>60 s</c>
					<c>2.27</c>
					<c>&lt;250ms</c>
					<c>Low</c>
					<c>Medium</c>

					<c>Glucose sensor</c>
					<c>250 s</c>
					<c>0.528</c>
					<c>&lt;250ms</c>
					<c>Medium</c>
					<c>Medium</c>
				</texttable>
			</section>

			<section title="Patient monitoring for Chronic Diseases">
				<t>For a chronic disease patient, the formal procedure of 
				routine visits is required to monitor the progress, development 
				of complications or relapse of the disease. The questions like 
				what, how and when to monitor are really crucial for disease 
				treatment. In this context, various biosensors can be used for 
				monitoring the patient's physiological conditions which brings 
				relevant information on a regular basis. Appendix A and B shows 
				patient monitoring use case scenario for WBAN.</t>
			</section>			

			<section title="Elderly Patient Monitoring ">			
				<t>The fast growth in the elderly population will produce a 
				considerable shortage of healthcare experts in the near future. 
				WBAN delivers a highly cost effective solution to monitor the 
				physiological parameters of the elderly persons by seamless 
				integration of their daily routine activities. Moreover, the 
				physician can monitor the health conditions of an elderly person 
				remotely by the courtesy of WBANs.</t>
			</section>							
	</section>

	<section title="Why 6lo is required for IEEE 802.15.6">
	    	<t>Based on the characteristics defined in the overview section, 
			the following sections elaborate on the main problems with IP for 
			WBANs.</t>
			
			<section title="IPv6 Connectivity requirements">
				<t>The requirement for IPv6 connectivity within WBANs is driven 
				by the following:</t>
				<t>
				<list style="symbols">
					<t> The number of devices in WBANs makes network auto 
					configuration and statelessness highly desirable. And for 
					this, IPv6 has (default auto-configuration as a) ready 
					solutions.</t>
					
					<t> The large number of devices poses the need for a large 
					address space, moreover a WBAN may consist of 256 nodes 
					maximum and IPv6 is helpful to solve addressing issues.</t>
					
					<t> Given the limited packet size of WBANs, the IPv6 address 
					format allows subsuming of IEEE 802.15.6 addresses if so 
					desired.</t>
					
					<t> Simple interconnectivity to other IP networks including 
					the Internet.</t>

					<t>However, given the limited packet size, headers for IPv6 
					and layers above must be compressed whenever possible.</t>					
				</list>
				</t>
				
				<t>However, given the limited packet size, headers for IPv6 and 
				layers above must be compressed whenever possible.</t>
			</section>
			
			<section title="Limited Packet Size">
				<t>Applications within WBANs are expected to originate small 
				packets. Adding all layers for IP connectivity should still 
				allow transmission in one frame, without incurring excessive 
				fragmentation and reassembly. Furthermore, protocols must be 
				designed or chosen so that the individual "control/protocol 
				packets" fit within a single 802.15.6 frame. Along these lines, 
				IPv6's requirement of sub-IP reassembly may pose challenges for 
				low-end WBANs healthcare devices that do not have enough RAM or 
				storage for a 1280-octet packet <xref target="RFC2460"></xref>.</t>
			</section>

			<section title="Topology requirements">
				<t>The IEEE 802.15.6 working group has considered WBANs to 
				operate in either a one-hop or two-hop star topology with the 
				node in the centre of the star being placed on a location like 
				the waist. Two feasible types of data transmission exist in the 
				one-hop star topology: transmission from the device to the 
				coordinator and transmission from the coordinator to the device. 
				The communication methods that exist in the star topology are 
				beacon mode and non-beacon mode. In a two-hop start WBAN, a 
				relay-capable node may be used to exchange data frames between a 
				node and the hub.</t>
			</section>					
	</section>	
	
	
    <section title="Scope/Purpose">
    	<t>This is a standard for short-range, wireless communication in the 
		vicinity of, or inside, a human body (but not limited to humans). It 
		uses existing industrial scientific medical (ISM) bands as well as 
		frequency bands approved by national medical and/or regulatory 
		authorities. Support for quality of service (QoS), extremely low power, 
		and data rates from 10Kbps to 10 Mbps is required while simultaneously 
		complying with strict non-interference guidelines where needed. The 
		Table 1 shows a comparison of WBAN and other available technologies in 
		terms of data rate and power consumption.</t>

		<texttable anchor="table_COMPARISON" title="Comparison of WBAN">
			<ttcol align='center'>Standard</ttcol>
			<ttcol align='center'>Provided data rate</ttcol>
			<ttcol align='center'>Power requirement</ttcol>
			<ttcol align='center'>Battery lifetime</ttcol>			
			<c>802.11 ac (WiFi)</c>
			<c>700 Mbps</c>
			<c>100 mW - 1000 mW</c>
			<c>Hours - days</c>			
			<c>Bluetooth</c>
			<c>1Mbps - 10 Mbps</c>
			<c>4 mW - 100 mW</c>
			<c>Days - weeks</c>			
			<c>Wibree</c>
			<c>600 Kbps maximum</c>
			<c>2 mW - 10 mW</c>
			<c>Weeks - months</c>			
			<c>ZigBee</c>
			<c>250 Kbps</c>
			<c>3 mW - 10 mW</c>
			<c>Weeks - months</c>			
			<c>802.15.4</c>
			<c>250 Kbps maximum</c>
			<c>3 mW - 10 mW</c>
			<c>Weeks - months</c>			
			<c>802.15.6</c>
			<c>1Kbps - 10 Mbps</c>
			<c>0.1 mW - 2 mW</c>
			<c>Months - years</c>						
		</texttable>		

		<t>The purpose of this document is to provide an international standard 
		for a short-range (i.e., about human body range), low power, and highly 
		reliable wireless communication for use in close proximity to, or 
		inside, a human body. Data rates, typically up to 10Mbps, can be 
		offered to satisfy an evolutionary set of entertainment and 
		healthcare services. Current personal area networks (PANs) do not 
		meet the medical (proximity to human tissue) and relevant 
		communication regulations for some application environments. They 
		also do not support the combination of reliability, QoS, low power, 
		data rate, and non-interference required to broadly address the 
		breadth of body area network (BAN) applications.</t>
	</section>

	<section title="Layer 2 Overview">
	    	<t>All nodes and hubs (coordinator in 802.15.4) are to be organized 
			into logical sets, referred to as body area networks (BANs) in this 
			specification, and coordinated by their respective hubs for medium 
			access and power management as illustrated in Table 1. There is to 
			be one and only one hub in a BAN, whereas the number of nodes in a 
			BAN is to range from zero to mMaxBANSize. In a one-hop star BAN 
			<xref target="SURVEY-WBAN"></xref><xref target="RFC7326"></xref>, 
			frame exchanges are to occur directly between nodes and the hub of 
			the BAN. In a two-hop extended star BAN, the hub and a node are to 
			exchange frames optionally via a relay-capable node. Some of the 
			characteristics of WBANs are as follows:</t>
			
			<section title="Frame format">
				<t>Figure 1 shows the general MAC frame format consisting of a 
				56-bit header, variable length frame body, and 18-bit FrameCheck 
				Sequence (FCS). The maximum length of the frame body is 255 
				octets. The MAC header further consists of 32-bit frame control, 
				8-bit recipient Identification (ID), 8-bit sender ID, and 8-bit 
				WBAN ID fields. The frame control field carries control 
				information including the type of frame, that is, beacon, 
				acknowledgement, or other control frames. The recipient and 
				sender ID fields contain the address information of the 
				recipient and the sender of the data frame, respectively. The 
				WBAN ID contains information on the WBAN in which the 
				transmission is active. The first 8-bit field in the MAC frame 
				body carries message freshness information required for nonce 
				construction and replay detection. The frame payload field 
				carries data frames, and the last 32-bit Message Integrity Code 
				(MIC) carries information about the authenticity and integrity 
				of the frame.</t>
				
		<figure anchor="wban-frame-format" title="The general MAC frame format of IEEE 802.15.6"> 
		<artwork><![CDATA[
                    Octets      7          0-255            2          
                           +--------+------------------+--------+     
                           |  MAC   |  MAC frame body  |        |     
                           | header |Variable length:  |   FCS  |  
			   |        |  0-255 bytes     |        |
                           +--------+------------------+--------+     
                           <--MHR--><--------X--------><---FTR-->       
                            /       \                                
                           /         \                                
                          /           \                               
         +---------+------------+-------------+--------------+        
         |  Frame  | Recipitent |   Sender    |      Ban     |        
         | control |     ID     |     ID      |       ID     |        
         +---------+------------+-------------+--------------+        
  Octets <--------><-----------><------------><-------------->  		
		]]></artwork></figure>
			</section>
			
			<section title="Frequency bands">
				<t>The USA Federal Communications Commission (FCC) and 
				communication authorities of other countries have allocated the 
				MICS band at 402-405 MHz with 300 KHz channels to enable 
				wireless communication with implanted medical devices [[[REFERENCE TO BE ADDED]]]. This 
				leads to better penetration through the human tissue compared to 
				higher frequencies, high level of mobility, comfort and better 
				patient care in implant to implant (S1), implant to body surface 
				(S2) and implant to external (S3) scenarios. Additionally, the 
				402-405 MHz frequencies offers conducive propagation 
				characteristics for the transmission of radio signals in the 
				human body and do not cause severe interference for other radio 
				operations in the same band. In fact, the MICs band is an 
				unlicensed, ultra-low power, mobile radio service for 
				transmitting data to support therapeutic or diagnostic operation 
				related to implant medical devices and is internationally 
				available. It is specifically chosen to provide low-power, small 
				size, fast data transfer as well as a long communication range 
				<xref target="SURVEY-WBAN"></xref><xref target="MAC-WBAN"></xref>. 
				The frequency range of the MICS band allows high-level 
				integration with the radio frequency IC (RFIC) technology, which 
				leads to miniaturization and low power consumption. The PHY 
				layer of IEEE 802.15.6 is responsible for the following tasks: 
				activation and deactivation of the radio transceiver, Clear 
				channel assessment (CCA) within the current channel and data 
				transmission and reception. The choice of the physical layer 
				depends on the target application: medical/non-medical, in, on 
				and off-body. The PHY layer provides a procedure for 
				transforming a physical layer service data unit (PSDU) into a 
				physical layer protocol data unit (PPDU). IEEE 802.15.6 has 
				specified three different physical layers: Human Body 
				Communication (HBC), Narrow Band (NB) and Ultra-Wide Band (UWB). 
				Various frequency bands are supported and shown in Table 2.</t>
				
				<texttable anchor="table_FREQUENCY" title="Frequency bands and 
				Channel bandwidth of IEEE 802.15.6">
					<ttcol align='center'>Communication</ttcol>
					<ttcol align='center'>Frequency</ttcol>
					<ttcol align='center'>Bandwidth</ttcol>
					<c>HBC</c>
					<c>16 MHz</c>
					<c>4 MHz</c>
					<c>HBC</c>
					<c>27 MHz</c>
					<c>4 MHz</c>					
					<c>NB</c>
					<c>402-405 MHz</c>
					<c>300 KHz</c>
					<c>NB</c>
					<c>420-450 MHz</c>
					<c>300 KHz</c>
					<c>NB</c>
					<c>863-870 MHz</c>
					<c>400 KHz</c>
					<c>NB</c>
					<c>902-928 MHz</c>
					<c>500 KHz</c>
					<c>NB</c>
					<c>956-956 MHz</c>
					<c>400 KHz</c>
					<c>NB</c>
					<c>2360-2400 MHz</c>
					<c>1 MHz</c>
					<c>NB</c>
					<c>2400-2438.5 MHz</c>
					<c>1 MHz</c>
					<c>UWB</c>
					<c>13.2-4.7 GHz</c>
					<c>499 MHz</c>
					<c>UWB</c>
					<c>6.2-10.3 GHz</c>
					<c>499 MHz</c>					
				</texttable>
			</section>
			
			<section title="Channel modes of IEEE 802.15.6">
					<t>o  Beacon Mode with Beacon Period Superframe Boundaries:</t>
					<t>Beacons are sent at beacon periods by the coordinator and 
					the superframe structure is managed by the coordinator by 
					using beacon frames. The Physical Protocol Data Unit (PPDU) 
					frame of Narrowband (NB) consists of a PHY Service Data Unit 
					(PSDU) and Physical Layer Convergence Procedure (PLCP).  
					PLCP preamble supports the receiver for synchronization 
					process and considers as first module being send at given 
					symbol rate. PLCP header sends decoding information for the 
					receiver and it is transmitted after PLCP preamble.  PSDU is 
					last module of PPDU and consists of MAC header, Frame Check 
					Sequence (FCS) and MAC frame body. PSDU is transmitted after 
					PLCP with help of available frequency band with specific 
					data rates.  Different modulations schemes can be used with 
					NB, namely, Differential Binary Phase-shift Keying (DBPSK), 
					Differential Quadrature Phase-shift Keying (DQPSK) and 
					Differential 8-Phase-shift Keying (D8PSK).  NB uses seven 
					frequency bands and operates under different data rates and 
					modulation schemes. Medical Implant Communication Service 
					(MICS) is the first licensed band of NB and used for implant 
					communication with range of 402-405 MHz in most countries. 
					Lower frequencies possess less attenuation and shadowing 
					effect from body.  Wireless Telemetry Medical Services 
					(WMTS) is another license band and used for telemetry 
					services. Although, Industrial, Scientific and Medical (ISM) 
					band is free worldwide but it generates high probability of 
					interference for IEEE 802.15.4 and IEEE 802.15.6 devices and 
					considered as 7th license-free band. The 6th band (2360-2400 
					MHz) is used for medical devices instead of ISM band and 
					offers less interference.</t>
					
					<t>The superframe structure consists of several phases: 
					exclusive access phase 1 (EAP 1), random access phase 1 
					(RAP1), type I/II phase, an EAP 2, RAP 2 and contention 
					access phase (CAP). CSMA/CA or slotted Aloha is used by 
					EAPs, RAPs and CAPs. For emergency services and high 
					priority data, the EAP 1 and EAP 2 are used, whereas, CAP, 
					RAP 1 and RAP 2 are used for regular data traffic. Type I/II 
					are used for bi-link allocation intervals, up-link and 
					down-link allocation intervals and delay bi-link intervals. 
					For resource allocation, the type I/II polling is used.</t>
					
					<t>A node's backoff counter value is set to a random integer 
					number in the range [1,CW (Contention Window)], where CW 
					(default value is CWmin) belongs to CWmin and CWmax which is 
					dependent on user priority. When the algorithm starts, node 
					begins counter decrement by one for every idle CSMA/CA slot 
					duration (slot duration is equal to Pcsma/CA slot length). A 
					node considers a CSMA/CA slot idle if the channel has been 
					idle between start of slot and pCCATime. When the backoff 
					counter reaches zero, the node transmits the data frame. In 
					case the channel is busy because of some other frame 
					transmission, then node locks its backoff counter until the 
					channel gets idle. The value of CW get double in case of 
					even number of failures until it reaches CWmax 
					<xref target="CHALLENGES-WBAN"></xref>
					<xref target="RFC7548"></xref>.</t>		
					
					<t>o  Beacon Mode with Superframe Boundaries:</t>
					<t>For this mode, the coordinator provides an unscheduled 
					polled allocation and each node establishes its own 
					schedule. Different access mechanisms are used in superframe 
					phases: schedule access (connection oriented and 
					contention-free access), improvised and unscheduled access 
					(connectionless and contention free access) and random 
					access (CSMA/CA or slotted Aloha based).</t>

					<t>o  Beacon Mode without Superframe Boundaries:</t>
					<t>In this channel access mode, beacons are not transmitted 
					and channel is assigned by using polling mechanism.</t>   		
		</section>
	</section>

	<section title="--IETF to standardize--">
		<t>This draft intend to standardize IEEE 802.15.6 for WBANs, 
		specifically for implantable and wearable sensors. By standardizing 
		means that integration of frame format need to be done i.e., how the 
		IEEE 802.15.6 frame format will communicate with IPv6? How 6LoWPAN can 
		accommodate this different frame format? The purpose of the mentioned 
		use cases is to highlight the importance of the standard.</t>	
		
		<t>The 6LoWPAN is used to provide integration between IEEE 802.15.4 and 
		IPv6. The details are mentioned in <xref target="RFC7548"></xref>. The 
		6LoWPAN concept originated with the purpose of connectivity of internet 
		protocol with low-power smaller devices so they could claim to be part 
		of Internet of Things (IoT) Networks.</t>
		
		<t>The 6LoWPAN group has defined encapsulation and header compression 
		mechanisms that allow ipv6 packets to be sent and received over IEEE 
		802.15.4 based networks, similarly the draft intent to define these 
		mechanisms for IEEE 802.15.6. The 6LoWPAN can not be used with IEEE 
		802.15.6 due to frame size differences of IEEE 802.15.4 and IEEE 
		802.15.6. </t>
	</section>

	<section anchor="IANA" title="IANA Considerations">
		<t>[TBD]</t>
	</section>

    <section title="Security Considerations">
    	<t>IPv6 over WBAN's applications often require confidentiality and 
		integrity protection. This can be provided at the application, transport, 
		network, and/or at the link.</t>
    </section>

	<section anchor="Acknowledgements" title="Acknowledgements">
      <t>[TBD]</t>
    </section>
    
</middle>

<!--  *****BACK MATTER ***** -->
<back>
    <!-- References split into informative and normative -->
    
    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
     (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
     
     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">

      &rfc2119;
      &rfc7548;      
	  &rfc7326;
	  &rfc2460;
	  &rfc4944;
    </references>
    
 <references title="Informative References">
			&id.draft-ietf-6tisch-6top-sf0;
			&id.draft-satish-6tisch-6top-sf1;
			
	<reference anchor="IEEE802.15.6" target="https://standards.ieee.org/findstds/standard/802.15.6-2012.html">
        <front>
			<title>IEEE Standard, 802.15.6-2012 - IEEE Standard for Local and metropolitan area networks - Part 15.6: Wireless Body Area Networks</title>
			<author></author>
			<date month="" year="2012"/>
        </front>
    </reference>
	
	<reference anchor='SURVEY-WBAN'>
        <front>
		<title>Wireless body area networks: A survey</title>
          <author initials="W." surname="Diffie">
          </author>
          <author initials="" surname="Samaneh Movassaghi"></author>
		  <author initials="" surname="Mehran Abolhasan"></author>
		  <author initials="" surname="Justin Lipman"></author>
		  <author initials="" surname="David Smith"></author>
		  <author initials="" surname="Abbas Jamalipour"></author>
          <date year="2014" month="" />
        </front>
           <seriesInfo name="Communications Surveys and Tutorials, IEEE" value=""/>
            <seriesInfo name="vol." value="16"/>
            <seriesInfo name="no." value="3"/>
           <seriesInfo name="pp." value="1658-1686"/>
     </reference>
	  
	<reference anchor='MAC-WBAN'>
        <front>
		<title>A MAC Protocol for Medical Monitoring Applications of Wireless Body Area Networks.</title>
          <author initials="" surname="Minglei Shu"></author>
		  <author initials="" surname="Dongfeng Yuan"></author>
		  <author initials="" surname="Chongqing Zhang"></author>
		  <author initials="" surname="Yinglong Wang"></author>
		  <author initials="" surname="Changfang Chen"></author>
          <date year="2015" month="" />
        </front>
           <seriesInfo name="Sensors" value=""/>
            <seriesInfo name="vol." value="15"/>
            <seriesInfo name="no." value="6"/>
    </reference>

	<reference anchor='CHALLENGES-WBAN'>
        <front>
		<title>A Survey on Wireless Body Area Networks: Technologies and Design Challenges.</title>
          <author initials="" surname="Riccardo Cavallari"></author>
		  <author initials="" surname="Flavia Martelli"></author>
		  <author initials="" surname="Ramona Rosini"></author>
		  <author initials="" surname="Chiara Buratti"></author>
		  <author initials="" surname="Roberto Verdone"></author>
          <date year="2014" month="" />
        </front>
           <seriesInfo name="IEEE Communications Surveys and Tutorials" value=""/>
            <seriesInfo name="vol." value="16"/>
            <seriesInfo name="no." value="3"/>
           <seriesInfo name="pp." value="1635-1657"/>
    </reference>

    </references>
	<section title="Patient monitoring use case - Spoke Hub">
	<t/>
		<t>Refer following diagram:</t>

		<figure anchor="patient-monitoring-usecase1" title="Patient monitoring use case - Spoke Hub"> 
		<artwork><![CDATA[
                              ########           
                            # @ EEG    #                              
                          ##   |      @ # Hearing              
                          #    |      | #                             
                           #   |      |#                              
                            #  |     #|            
                      #####    |      |## ###                     
                   #           |      |   @   ## Motion Sensor                     
       Positioning#  @         |      /  /     #                      
                 #    \        |ECG /  /       #                     
                 #     \       |  @ | /         #                                
                #         \    | / / /           #                     
               #      ##   \   |/ //      ##      #                    
               #      ##    \  ||//       ##      #                  
              #      # #     \ ||||      # #  @   # BP                   
             #       # #      \||||      # # /    ##                  
             #      ## #       ||||      # #/      ##                 
        SPO2# @    ##  #   Coordinator   # /##      #                 
           #   \  ##  ##       +-+        /  ##     ##                
          #     ------+--------| |-------/ #   #      #                
       ##     ##      #        +-+         ##     #    ##              
     ##      ##      #         //\         #      #      ##           
  ###       #        #        //  \        #      ##        ###       
    ##      #        #       //    \       #       #      ## ##       
    #      #        #       //      \      #        #      #          
   ###   # #        #      //  ##    \     #        #     ###         
     #  ###         #     //   # #    \    #         # #  ###         
     ###            #    //   # #     |    #          # ###           
                    #   //    # ##    |    #                          
     Glucose Sensor # @ /     #  #    |   #                           
                    ##  |     ##  #    |   #                           
                     # /      #   #    |   #                           
                     #/     #      #  |   #                           
                 Emg#@      #      #  |   #                           
                    #      #       ## |   #                           
                    ##              # |   #                           
                     #    #         # |   #                           
                     #    #          #\   #                    
                    #     #          # |   #                       
                    #     #          # @   # Motion Sensor                         
                     ##  #            ## ##                           
                       ##               #                   		
		]]></artwork></figure>		
    </section>

	<section title="Patient monitoring use case - Connected">
	<t/>
		<t>Refer following diagram:</t>

		<figure anchor="patient-monitoring-usecase2" title="Patient monitoring use case - Connected"> 
		<artwork><![CDATA[
                              ########           
                           #   @ EEG    #                              
                          ##   |\-----@ # Hearing              
                          #     |      \#                             
                           #    |     # |                             
                            #    |   ##  |Motion Sensor         
                    #######      |     ##|####                     
                   #              |       |   ##                      
       Positioning#   @            |      @    #                      
                 #    /\        ECG|       \   #                     
                 #   /  \----------@        \   #                     
                #   /                        |  #                     
               #  /   ##                 ##   |  #                    
              # /    # #                 # #  @   # BP                   
             #/     ## #                 # ##  |   ##                 
        SPO2# @    ##  #                 #  ## |    #                 
          #    \ #    #                   #   #|     #                
       ##     ## \    #                   ##   | #    ##              
    ##      #      \ #                     #  |    #      ## ##       
   ###   # #        # \        ##          #  |     #     ###         
     #  ###         #   \      # #          # |       # #  ###         
     ###            #   |     # #          # |        # ###           
                    #   |     # ##         # |                        
     Glucose Sensor #   @     #  #        #  |                        
                     # /     #    #       # /                         
                     #|    ##      #      #/                          
                     #/     #      #      #|                          
                 Emg#@      #      #      #|                          
                    #  \    #      #      #|                          
                    #    \  #      #      #|                          
                    #     \#       ##     #|                          
                    ##     \        #     #|                          
                     #     #\       #     #|                          
                     #    #  \      #     #|                          
                     #    #    \    #     #|                          
                     #    #     \   ##    #/                           
                     #    #       \ ##    /                 
                     #    #        \ ##  /#                    
                    ##    #          \  |  #                          
                    #     #          # \/  #                       
                     #    #           # @ # Motion Sensor                                         
                       ##               #                    		
		]]></artwork></figure>				
    </section>	

</back>
</rfc>
